I did spend some time trying to integrate STEPCode 0.8.2 a while back. I ran into problems mostly with Windows and set it to the side.

Recently, there has been quite a bit of progress with STEPCode (not by the main author, someone else has been making a lot of changes). I took another stab at integrating his latest work (skipping 0.8.2). Considering how much progress he has made, I would prefer to go that way.

stepcode/stepcode#469 (comment)

Unfortunately, I ran into the same sort of problems I ran into with 0.8.2. The fundamental issue is that STEPCode is a small esoteric project and when progress on the build system has been made recently, it has not been fully tested cross platform and for both static and dynamic libraries.

STEPCode's build system is not just for compiling some files. It first compiles a schema parser/compiler and then it parses the required STEP specification - generating C++ code -- that then gets compiled into the library that gets linked into projects like OpenVSP. A huge amount of STEPCode's work is the build system.

So, I certainly want to update STEPCode (to the development branch), but it has to be done in a way that works across Windows/Mac/Linux and results in static libraries to link into OpenVSP. Once it builds, we at least need to do a minimal amount of functional testing.

On the fedora side, the bundled STEPCode is a showstopper starting with Fedora 44 (i.e. the next one). GCC-14 is no longer included, and that's the latest GCC that compiles STEPCode.

The fix I have is a pretty kludge sed replace that bypasses some tests in the stepcode build.

Here is a link to the latest build. Could you share the test framework or put the build through your tests to see if it works? If it does, I'll maintain a branch until the latest stepcode is integrated.

If you push a branch called build to a GitHub fork with GitHub Actions activated, it will build according to the recipe here:

https://github.com/OpenVSP/OpenVSP/blob/main/.github/workflows/build.yml

This is how I build the official releases.

You might want to go in and remove some of the combinations from the build matrix to make things go faster. The build matrix is lines 14-29. You can remove things from lines 14 & 15, but if there is a subsequent 'include' statement, it will add that platform back into the matrix (even if it was deleted from 14/15). So, if I am doing a test build, I will trim this file down to something like:

        python-version: [3.13]
        os: [ windows-2022, ubuntu-24.04, macos-14 ]
        include:
          - os: ubuntu-24.04
            gcc-version: 13
          - os: macos-14
            llvm-version: 18

That will build just three builds, one Mac, one Ubuntu, and one MacOS.

Theoretically, this should be free if you build on a public repository. However, I have lately had some problems with GitHub charging me for some of these builds. I am trying to sort it out with their Tech support.

As for functional testing, to start, just use an old version, make a simple model (even just a pod would be a good start), and export an unintersected *.stp file. Then, do the same thing with the new version -- if it doesn't crash, then compare the two *.stp files (they are text, so you can compare with diff). They should be the same. If it passes that test, then we're probably fine.

It is probably fine to do the functional testing on just one platform (your Fedora is fine) and just the build system testing across all the platforms.

I've pushed up my STEPCode update WIP. It might work for you on Fedora. If not, it is what I will try to develop a long-term solution around, so it is a better place for you to work if you need to spend more time on this.

https://github.com/ramcdona/OpenVSP/tree/STEPCode_Update

Looking over that link, as well as #160 and #155, it looks like most of the issue is in the Cmake. Packaging STEPCode on its own might be easier to do than trying to patch it through VSP in the case of Fedora (and other linux distros).

That said, the Raw() method is obsolete and still used by VSP. You seem to understand it more than me, although the 1:1 replacement with ptr seems to work (still haven't done a function test). If I can build STEPCode as a systemlibrary, and if replacing Raw() is ok, then packaging on Fedora is a solved problem. Am I missing anything?

In the branch I posted, I thought all the usages of Raw() were fixed...

b0fbfd1

Does Fedora ship an 'official' version of STEPCode? If so, what version are they on?

STEPCode is an esoteric library that is not well maintained. I would not expect Fedora to have an official bundled version of the library. Consequently, there is no real benefit of using the system library vs. bundled.

If you use the bundled version -- but can only get it working with shared libraries -- then you'll have the complication of having to provide / install / distribute the compiled shared libraries. So, unless it is a package provided by the operating system, it is generally preferable to use static linking.

I agree that the problems with STEPCode right now are mostly build system / CMake stuff. I do think you can find a solution that will work for your needs.

Yes, I saw you fixed Raw(). My mistake. I can pull that for the 3.47 release (or maybe 3.48.2, tbd).

Fedora does not have a STEPCode package. My sponsor asked me to take a crack at some of the dependencies first, including STEPCode. I am not going to do all of them, but some are easy and I took a stab at them.

STEPCode is probably not in that category. exp2cxx is required and needs some sort of function test after compiling, although the test suite of stepcode may cover it. The rpm .spec script has a dedicated process for this kind of thing, called a %check section.

I don't know how schemas work. Is ap203 part of vsp and interpreted by stepcode, or is it bundled in stepcode? If it is only a question of making exp2cxx available when vsp compiles, it's a relatively trivial job and shouldn't cause any weirdness, as it should be callable with find_program().

The STEP standard actually defines a schema to define the contents and format of other files. That schema is called Express. It then includes a bunch of implementations of that schema that define different file types. ap203 is one implementation that is provided with the STEPCode distribution. It is pretty much the most simple STEP schema for geometry information. There are others that handle things like electronics, manufacturing, and other parts of product lifecycle.

So yes, exp2cxx is only used during build time. First it is compiled, then it is used to convert the ap203 spec into cpp and h files. Then STEPCode compiles those into libraries that are used by end applications.

I'm not exactly sure what your sponsor's goal is (with respect to all these dependencies), but in general...

fltk, glew, glm, and libxml2 are the only libraries that I would expect could reasonably be supplied by the Linux distribution's packaging system (i.e. system provided libraries).

angelscript might be provided by the OS. We used to carry a lot of modifications to their build system, but I'm pretty sure we're aligned with the mainline now. We're a version or two behind the newest, but it shouldn't be a problem to update.

cminpack and Clipper2 might be available with the packaging system

eigen is a big library and will be packaged -- but it is header only, so there isn't a benefit to using a system packaged library.

Delabella is unlikely to be provided, We have carried our own changes to it at some points in the past.

Code-Eli is an internal library, it won't be packaged. It is header only, so it wouldn't matter anyway.

Cpptest will be available through the packaging system, but it is only used for 'make test', not for release builds.

exprparse - is a tiny library that was developed by our team. It won't be packaged.

OpenABF - small library, unlikely to be packaged

Pinocchio -- small library, unmaintained, won't be packaged

Triangle - The original C implementation of this might be available as a library, but we use a C++ wrapper that is unlikely to be packaged.

This PR incorporates your changes to CADutil.cpp. I preserved most of my changes elsewhere. I'm also using a more recent STEPCode version, which builds successfully at least on Fedora x86_64 (both in vsp and stand-alone). I've had trouble with it stand-alone on aarch64, which might be the source of your problems getting it to run multi-platform.

For the record, I think my original fix to eliminate the tests was wrong; it was likely breaking things silently. This latest version fails tests on aarch64.

I changed some CMAKE flags in External_stepcode to make it build properly. It builds successfully for both mac and linux, but fails on windows:
https://github.com/Mumbri-systems/OpenVSP/actions/runs/23847384734

All builds compile successfully.

The major issue was that win32 libs were almost all renamed. I see you have an open TODO to implement find_path and find_library instead of explicit lib paths, I think it may be time to make that a priority.