@ramcdona Does this help with the issue you were seeing?

I haven't been able to try this out yet, but I hope to soon.

The STEPCode I'm using is currently way behind what you've been doing. I know it is going to take a good amount of work to re-integrate STEPCode into my project. I would like to update, but I don't have time to chase a bunch of different branches.

Do you have a single branch with everything you're working in one place? It seems like a dynamic time -- what is the most stable place for me to start over?

The stepcode develop branch (not master) in the main repo should be fine unless you need to read the newest ap242 standard. I suppose it looks dramatic, but I'm actually trying to just hit the necessary cleanups for modern compilers/express files and stuff like the leftover old-style variables. There's more I'd like to do, but I doubt I'll have the bandwidth for much more anytime soon.

OK, thanks.

I'm still on a version from 2016 with a few fixes I needed to get it to build across platforms. So no matter what I'm in for a significant update.

First experience -- I haven't dug in much yet.

SC_INSTALL_PREFIX is ignored, switching to CMAKE_INSTALL_PREFIX fixes the issue.

Building with:

-DBUILD_STATIC_LIBS=ON
-DBUILD_SHARED_LIBS=OFF

causes

[174/187] Linking CXX executable bin/lazy_test
FAILED: [code=1] bin/lazy_test 
: && /usr/bin/c++ -O2 -g -DNDEBUG -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/homebrew/opt/openblas/lib src/cllazyfile/CMakeFiles/lazy_test.dir/lazy_test.cc.o src/cllazyfile/CMakeFiles/lazy_test.dir/sc_benchmark.cc.o -o bin/lazy_test  -lsteplazyfile  -lstepeditor && :
ld: library 'steplazyfile' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Keeping shared libs on allows this to proceed. Since I am only using static libraries and the build is contained within my SuperProject, I would prefer to not build anything that is not needed.

All the static libraries are now suffixed with -static. This (IMO) makes things like FindSTEPCode.cmake more complicated as the library names are now different static vs dynamic.

/lib/libbase.a is no longer a thing. It appears to not be needed.

My program is essentially the same as example/ap203min/ap203min.cpp.

The API has changed somewhat. I use Raw(), which does not exist anymore. I updated my use to match some changes Chris made to ap203min earlier and got past that.

/Users/ramcdona/Documents/OpenVSP/repo/src/util/CADutil.cpp:109:27: error: no member named 'Raw' in 'STEPattribute'
  109 |                     attr->Raw()->e = new SdaiSi_prefix_var( pfx );
      |                     ~~~~  ^

Line 713 of ap203min.cpp

instance_list->DeleteInstances();

Triggers a double-free crash. I'm not sure if that was always a problem (and I just missed it) or if it reflects another API change. However, commenting out the equivalent line in my program seems to have things working.

This is only on MacOS so far. I'll have to also try Windows and Linux (I had to have some odd platform specific CMake stuff before, hopefully that is better).

I haven't done much testing, but a trivially simple file seems to work.

Thanks for all your work on this.

I spent some time trying on Windows. It seems to be a mess.

With

-DBUILD_STATIC_LIBS=ON
-DBUILD_SHARED_LIBS=OFF

The library itself won't build. It fails to link on check-express.exe, exp2cxx.exe, exppp.exe and the like.

That is with lazy_test commented out entirely. If this is really a test, then it should be conditional on SC_ENABLE_TESTING.

However, with

-DBUILD_STATIC_LIBS=ON
-DBUILD_SHARED_LIBS=ON

STEPCode builds, and my application (which has hard-coded paths to the static libraries) will build. However, when it runs, it crashes because it can't find the *.dll's. It seems like the static libraries may actually have dependencies on the dynamic libraries or something. In any case, I have not been able to build and run a static application.

OK - I don't test or use the static libs myself, so it's not something I would have run into. As for the find_package bits, I imagine stepcode is actually a good candidate for the new Config.cmake style of supporting find_package. I'm less familiar with how that is set up, but I've done it once or twice. I'm working on something else right now, but once I can squeeze in some time I'll see if I can reproduce your issues with the STATIC libs and try to figure out what to do about them.

Very much appreciated. I figured this was a case of lack of test/use coverage.

Not only is the ap203min example pretty much the same code as I use -- it is set up to bootstrap STEPCode as an ExternalProject_add in essentially the same way I use it. So, that should provide a great test / example if you want to use it.

I was thinking about the modern CMake config approach when I was looking at this. I agree it could just take care of things in this regard. However, like you, I've never set up a project as complex as STEPCode with it.

Finally, have you been testing this with CMake 4+? I've been stuck at 3.X because of two dependencies (I think SC was one of them). I suspect you have, but I figured I would ask.

Thanks much for your willingness to dig into this and for all the work you've done taking over maintenance of STEPCode. I'm sure you want to avoid the role officially, but your efforts are noticed.