Discussion Orbiter SDK handling of Debug and Release builds

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,914
Reaction score
2,908
Points
188
Website
github.com
So, again with this old theme. :rolleyes:

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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,914
Reaction score
2,908
Points
188
Website
github.com
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,914
Reaction score
2,908
Points
188
Website
github.com
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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.
 
Top