Building Oolite Windows from source - The Easier Way

[Redspear]

Commander_X's 'quick fix' posted above appears to have done the trick!

Thanks so much to C_X and a_c for helping me out with this

Now I'm free to mangle the source code to suit my peculiar tastes

Redspear, have you changed user access privileges at any point recently? Check the shortcut used for msys.bat (right click, Properties, Advanced...). Is it set to run as administrator? You can try toggling this option and see if it helps.

That was certainly a possibility but no, I can run it as a regular 'user'. Thanks for investigating.

I haven't built it yet but I'll post back at some stage to (hopefully ) confirm a success!

Cheers!

[Redspear]

...I'll post back at some stage to (hopefully ) confirm a success!

Confirmed!

[Diziet Sma]

From the instructions in the OP:

2. Check out the oolite code:

Code: Select all

git clone https://github.com/OoliteProject/oolite.git

This will start copying the source code from the repository to your working dir. When finished, there will be a folder named oolite under the folder you performed the checkout. Next do a

Code: Select all

cd oolite

to enter in the trunk folder, where the actual build will take place. Finally, execute this command to pull in all the binary dependencies needed for the full build (maybe you can take a coffee break here, this takes a while):

Code: Select all

git submodule update --init

Suggestion; these steps can be combined by using:

Code: Select all

git clone --recursive https://github.com/OoliteProject/oolite.git

This command clones both the source and the submodules in the one step.

[another_commander]

A new version of the development environment for Windows has been uploaded. See first post for download link.

In this version:

• New git version (2.16.2), which uses the latest GitHub security protocols. If you tried to clone or pull from github and received an error, try again with this one.
• Latest home-made gnustep-base-1.20.1.dll,with include files and import libraries. This is capable of TLS downloads.
• New home-made SDL.dll + include files and import libraries, with embedded haptic devices and mousewheel delta support. This may come handy for upcoming features.

[Commander_X]

Great, this was due since a while. Luckily Cygwin's git (not hurt by github's measures) could handle mingw's repositories with no trouble.

[another_commander]

Following the commit of revision 36834ab, an updated version of the development environment is required to compile the Windows port. See the first post for the new download link.

The update is very simple and adds one line of code to the SDL_video.h header included in the environment. If you can't be bothered to re-download, you can update it yourself manually by doing the following:

Get the updated SDL_video.h file from here: https://github.com/OoliteProject/oolite ... DL_video.h . Then just replace the file in your dev environment located at <DevEnvPath>/gcc/Msys_x2/1.0/Devlibs/include/SDL with this one and you should be good to go.

[another_commander]

A new update to the Windows dev environment has been posted here. The first post of this topic has also been updated accordingly.

This version contains the necessary headers and updated import libraries to support detection of HDR capable devices under Windows and will be the required environment to compile the game binary once the HDR detection code has been committed to github.

[another_commander]

Please be advised that following the merge of PR #416 on github, the dev environment linked in the post above and on the first page of this topic is now a requirement for successfully building Oolite on Windows. Alternatively, you can download a zip of the full Windows dev environment from github by following this link, but note that this is a much bigger download, it is configured primarily for the github actions bot and is not as portable as the Light Edition you can get from this topic.

In any case, previous versions of the environment will not be able to build the game's code from revision 43b4781 onwards.

[hiran]

I'd be wondering who might prefer to build on their machine if the ready made builds are just available as well.
Speak up, surprise me!

[phkb]

I prefer to build!

[another_commander]

Basically anyone who wants to fiddle with the source code and experiment with stuff rather than just get a ready-made executable can benefit from having the actual environment that is used for building the game.

[hiran]

Basically anyone who wants to fiddle with the source code and experiment with stuff rather than just get a ready-made executable can benefit from having the actual environment that is used for building the game.

Well, I can already clone the source, change it and get it built without hassle on Github.
So maybe I want to compile locally if there are more advantages to it than just to include a simple modification.

One use case might be to compile using debug symbols and then go into a detailed debugging session I can still see the need for a local build.
Or a matter of preference for those who also compile their own Linux kernel. I was in that guild but stopped some years ago - when ready made kernels were modular and sufficiently well built.

[hiran]

Instructions on how to build an Oolite trunk executable from zero:

Lots of kudos for having created the windows build environment so long ago. If we had not that one, we'd probably not compile for Windows at all!

But now the question:
I can use the instructions to compile a trunk-based test version. What would need to change to get a test release, what for a normal (production) release?

All I can see is the call to msys.cmd here:
https://github.com/OoliteProject/oolite ... l.yml#L287

[Mauiby de Fug]

The type of build depends on the call to the Makefile: https://github.com/OoliteProject/oolite ... r/Makefile

As noted at https://github.com/OoliteProject/oolite ... kefile#L81 there are four different development targets, and at https://github.com/OoliteProject/oolite ... efile#L105 we can see the three different installer targets, one for each of the three different release builds.

The call to msys.cmd kickstarts the particular msys build environment that we have in the https://github.com/OoliteProject/oolite ... -build-env repository on GitHub Actions.

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_commander]

@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.