Discussion Orbiter SDK handling of Debug and Release builds

[GLS]

So, again with this old theme.

Since _ITERATOR_DEBUG_LEVEL became a thing, release libs don't link with debug builds and vice-versa. This makes addon development for post Orbiter 2016 versions a bit harder than before as an Orbiter installation will only support the compilation of the addon in either debug or release, and to compile in the other mode, Orbiter needs to be recompiled.

The options I see are:
a) start playing with _ITERATOR_DEBUG_LEVEL, and that might allow debug/release mixing again;
b) change the Orbiter build process so that both release and debug libs (e.g., Orbitersdk.lib and Orbitersdkd.lib) are generated, devs then link their builds to the correct libs;
c) change nothing, and let the devs handle Orbiter debug builds themselves.


Option b is the one that makes most sense to me.

 

[jarmonik]

I encountered this problem once with the gcAPI. Unless I am mistaking this problem only occur when passing "std::" data types such as std::vector<> through API interface. These data types are already used inside the Orbiter but the add-on side API should be clean and should stay that way. Since the Orbiter is a collection of high number of add-ons, not being able to mix them would be a major nightmare. I'll make some quick tests....

 

[jarmonik]

There appears to be no problems running LTMFD or IMFD (2016 versions) on debug build of Open Orbiter. So, Release add-on on Debug Orbiter isn't broken at-least in this test case. So I would assume that if std::vector alike data types aren't passed through API we should be clear of the problem, right ?

 

[GLS]

There appears to be no problems running LTMFD or IMFD (2016 versions) on debug build of Open Orbiter. So, Release add-on on Debug Orbiter isn't broken at-least in this test case. So I would assume that if std::vector alike data types aren't passed through API we should be clear of the problem, right ?

It's not the running that is the problem, but the building. Linking a debug build of a vessel or MFD to a release version of (post 2016) Orbiter will fail. Addon developers are now "forced" to always build in release mode, unless they compile their own debug Orbiter.

BTW: this only concerns the libs and not the executables.

 

[jarmonik]

Yes, you are correct. I get a link error LNK1319 when trying build. I would probably go with option (b) but I have no idea how to change GitHub's automated build process. Wouldn't the option (a) effect in debug ability if disabled and performance if always on.

 

[GLS]

I would probably go with option (b) but I have no idea how to change GitHub's automated build process.

I'm also unfamiliar with that build process, but my guess is that it should probably be something in cmake. I'll try to find out more info.
The end result should be:

> libs: both debug and release configs always generated
> vessels, MFDs, exe: generated selected config, using the correct libs
> package: everything built

Wouldn't the option (a) effect in debug ability if disabled and performance if always on.

That is my understanding: std container (vector, list, etc) debug would probably disappear. This makes option b much more appealing.

 

[jarmonik]

I haven't found any easy way to make those debug libs in cmake. If there's no better option available then we could manually compile the debug libs and copy them to a repository.

 

[GLS]

One idea I had was to have 2 projects for each lib: one only builds Debug and the other Release, and they are always built... not sure if that is possible in cmake.
But apparently there are other ways to make this happen: https://cristianadam.eu/20191012/building-multiple-configurations-with-cmake-in-one-go/