Building Oolite Windows from source - The Easier Way

[hiran]

@hiran: Mauiby already gave a very detailed answer and I don't think there is anything to add, you are in good hands with this.

Only minor correction I can offer is that the default build type currently in use is pkg-win-snapshot, which essentially is just a pkg-win test release build with a watermark.

What is this watermark? Just an extended version number?

Actually I added the different builds for Linux to also learn about the difference.

[another_commander]

The watermark is just a text on the top right corner of the game window with format "Development version 1.91.0.7545-231107-68519c6". This cannot be removed unless you binary edit the executable itself.

As for the differences between deployment and test release configurations, there are too many to list here, but the idea is that test releases contain more debug tools, allow connection with the debug console and are stricter in their boundary and limits checks. Supposedly there is a performance cost for this, but to be honest, I have not really noticed it. You can get an idea of the differences by looking at config.mak, which contains the default compile switches for test releases

Code: Select all

BUILD_WITH_DEBUG_FUNCTIONALITY = yes
NO_SHADERS                     = no
ESPEAK                         = yes
OO_CHECK_GL_HEAVY              = no
OO_EXCLUDE_DEBUG_SUPPORT       = no
OO_OXP_VERIFIER_ENABLED        = yes
OO_LOCALIZATION_TOOLS          = yes
DEBUG_GRAPHVIZ                 = yes
OO_JAVASCRIPT_TRACE            = yes
OO_FOV_INFLIGHT_CONTROL_ENABLED = no

vs the GNUmakefile which contains the default switches for the deployment configuration

Code: Select all

 ADDITIONAL_CFLAGS            += -DNDEBUG
 ADDITIONAL_OBJCFLAGS         += -DNDEBUG
 ADDITIONAL_CFLAGS            += -DOO_CHECK_GL_HEAVY=0
 ADDITIONAL_OBJCFLAGS         += -DOO_CHECK_GL_HEAVY=0
 ADDITIONAL_CFLAGS            += -DOO_EXCLUDE_DEBUG_SUPPORT=1
 ADDITIONAL_OBJCFLAGS         += -DOO_EXCLUDE_DEBUG_SUPPORT=1
 ADDITIONAL_CFLAGS            += -DOO_OXP_VERIFIER_ENABLED=0
 ADDITIONAL_OBJCFLAGS         += -DOO_OXP_VERIFIER_ENABLED=0
 ADDITIONAL_CFLAGS            += -DOO_LOCALIZATION_TOOLS=0
 ADDITIONAL_OBJCFLAGS         += -DOO_LOCALIZATION_TOOLS=0
 ADDITIONAL_CFLAGS            += -DDEBUG_GRAPHVIZ=0
 ADDITIONAL_OBJCFLAGS         += -DDEBUG_GRAPHVIZ=0
 ADDITIONAL_CFLAGS            += -DOO_FOV_INFLIGHT_CONTROL_ENABLED=0
 ADDITIONAL_OBJCFLAGS         += -DOO_FOV_INFLIGHT_CONTROL_ENABLEDD=0

But if you really want to see all the differences, you will have to dive into the source and find the occurrences of NDEBUG. The test release configuration does not define it, while the deployment one does.

[hiran]

The watermark is just a text on the top right corner of the game window with format "Development version 1.91.0.7545-231107-68519c6". This cannot be removed unless you binary edit the executable itself.

As for the differences between deployment and test release configurations, there are too many to list here, but the idea is that test releases contain more debug tools, allow connection with the debug console and are stricter in their boundary and limits checks. Supposedly there is a performance cost for this, but to be honest, I have not really noticed it.

Thank you for that overview. Likely I do not need 100% of the details. But as it seems there is still a justification for having the different releases. I will try to implement Maulby's suggestions.

[hiran]

The build command is actually located in the profile file at https://github.com/OoliteProject/oolite ... rofile#L76 and as such is automatically invoked when msys is started. As you can see, we currently build pkg-win, which makes a test release installer.

To change this you'd want to either work out how to pass a command into that environment so that you could have the build type as an argument (I have no idea how that would work), or to change the profile file.

My recommendation would be to use sed or similar to edit the profile file in a step after the Checkout DevelopmentEnvironment step but before the Compile step.

As the different build type is essentially just a different argument to the Makefile I'd also recommend the use of a matrix strategy when building (both in Windows and in Linux, as I can see that you're working on at the moment) and you'd more or less get it for free. I've done this with my own build experiments - feel free to use that for inspiration and give me a shout if you have any questions - I'm happy to help!

Another option could be to set a variable - profile is a shell script. I just cannot tell what shell exactly.
But: It allows for additional scripts to be sourced, see https://github.com/OoliteProject/oolite ... rofile#L46
If only I knew where in the windows filesystem that would be.

So I will try the easier way and use sed...

[hiran]

Now we have three windows and three linux builds. Here is a first glimpse
https://github.com/OoliteProject/oolite ... 09-e70feb4

Apparently there is a name clash as both pkg-win-deployment and pkg-win built

Code: Select all

OoliteInstall-1.91.0.e70feb4.exe

while pkg-win-snapshot produced

Code: Select all

OoliteInstall-1.91.0.e70feb4-dev.exe

Github automatically changed the filename by adding the md5 hash.

[hiran]

The naming collision is now resolved.
As opposed to normal releases, nightly builds contain a -dev and test releases a -test.