Building Oolite 4 Linux

[hiran]

Looking at github commit https://github.com/OoliteProject/oolite ... 7fd736afa5
with message Fixed compile error on Fedora 36.

Can someone elaborate how Oolite got built? If the instructions can be run on Ubuntu as well, I could assist creating a CI/CD pipeline that ensures we always get the latest build automatically. Right now this only applies to the Windows version.

[another_commander]

I think you may want to reach out to the reporter of issue #417. I am confident that the fix works because we've had similar reports in the past when compiling with recent gcc versions, but whether the issue reporter managed to successfully build a working executable or not at the end is not clear. I imagine they did because I had asked them to reopen the issue if the fix failed to work.

[tsoj]

Can someone elaborate how Oolite got built? If the instructions can be run on Ubuntu as well, I could assist creating a CI/CD pipeline that ensures we always get the latest build automatically. Right now this only applies to the Windows version.

This script should build Oolite on a clean Ubuntu install:

Code: Select all

#!/bin/bash

# install all the necessary packages
sudo apt update
sudo apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev libopenal-dev g++ libespeak-dev libnspr4-dev

# download source and dependencies
git clone https://github.com/OoliteProject/oolite.git
cd oolite
cp .absolute_gitmodules .gitmodules
git submodule update --init
git checkout -- .gitmodules

# this is necessary, as otherwise textures aren't loaded correctly
rm deps/Linux-deps/include/png.h
rm deps/Linux-deps/include/pngconf.h

# compiling
source /usr/share/GNUstep/Makefiles/GNUstep.sh
make -f Makefile release -j$(nproc)

[hiran]

This script should build Oolite on a clean Ubuntu install:

Nice!
I got it working in Github.

Now where in the filesystem would I find the files that need to be zipped up into a release?

[hiran]

I am still trying to assemble a build.

When I downloaded oolite-1.90.linux-x86_64.tgz I found that it contains one single file: A script to install the whole game.
This script is made by make_installer.sh - a nice wrapper that seems to be a one stop shopping.

But apparently I am not able to make it fly. Which directory do you run it from? What parameters should be used? Do you need to build Oolite before, or will that be taken care of?

[Commander_X]

I thought you've got it working earlier?

NB: don't forget a_c observation later in the thread about ". /usr/GNUstep/System/Library/Makefiles/GNUstep.sh " (dot space forward slash at the beginning, shortcut for "source /usr/GNUstep/System/Library/Makefiles/GNUstep.sh").

[hiran]

I thought you've got it working earlier?

That attempt never made it into the Oolite repository. But thank you for remembering.

NB: don't forget a_c observation later in the thread about ". /usr/GNUstep/System/Library/Makefiles/GNUstep.sh " (dot space forward slash at the beginning, shortcut for "source /usr/GNUstep/System/Library/Makefiles/GNUstep.sh").

I checked - it is contained in the above example.

[tsoj]

Now where in the filesystem would I find the files that need to be zipped up into a release?

I played around a bit and managed to make it work (maybe?) with the following updated script:

Code: Select all

#!/bin/bash

# install all the necessary packages
sudo apt update
sudo apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev libopenal-dev g++ libespeak-dev libnspr4-dev

# download source and dependencies
git clone https://github.com/OoliteProject/oolite.git
cd oolite
cp .absolute_gitmodules .gitmodules
git submodule update --init
git checkout -- .gitmodules

# compiling and creating the self-extracting installer
source /usr/share/GNUstep/Makefiles/GNUstep.sh
make -f Makefile pkg-posix-nightly HOST_ARCH=x86_64

Then the Linux install file should be (for example) at ./installers/posix/oolite-trunk-1.91.0.a911f5a-dev.linux-x86_64.run.

We need to set HOST_ARCH manually as the Makefile doesn't set it automatically (maybe we should update either the Makefile or at least the help command for the Makefile).
The removal of some png header files also had to go, as apparently they weren't there for no reason ... And the textures seem fine when installing from the resulting installer, so no problem here.

EDIT: I also see, I need to update my signature. I'm currently flying a Cobra Mark II-X ...

EDIT2: Nevermind, it doesn't work on another Linux install

[hiran]

I played around a bit and managed to make it work (maybe?) with the following updated script:
[...]

Then the Linux install file should be (for example) at ./installers/posix/oolite-trunk-1.91.0.a911f5a-dev.linux-x86_64.run.

Worked for me. Thank you, we have the installer back.

We need to set HOST_ARCH manually as the Makefile doesn't set it automatically (maybe we should update either the Makefile or at least the help command for the Makefile).
The removal of some png header files also had to go, as apparently they weren't there for no reason ... And the textures seem fine when installing from the resulting installer, so no problem here.

No problem. Although we should never see any 32 bit systems around any more, something can still change. I replaced it with

Code: Select all

$(uname -m)

.

EDIT: I also see, I need to update my signature. I'm currently flying a Cobra Mark II-X ...

EDIT2: Nevermind, it doesn't work on another Linux install

Do not worry. This is exactly the issue why I could not move on last time.
Now I would say: It is the best we have, let's preserve it.

So I have a running Github workflow that builds both Windows and Linux. For some reason the release is failing. I'd like to figure that out, then I will raise a PR.

[hiran]

So I have a running Github workflow that builds both Windows and Linux. For some reason the release is failing. I'd like to figure that out, then I will raise a PR.

Fixed. It was just a permission issue.
So now I could see the release to get created, and I downloaded it and was able to run it on my Ubuntu 22.

[tsoj]

Fixed. It was just a permission issue.
So now I could see the release to get created, and I downloaded it and was able to run it on my Ubuntu 22.

Nice!

Do not worry. This is exactly the issue why I could not move on last time.

I think the issue is that the binary is compiled against different versions of libraries than what is here. So my idea is to just copy all the libraries that the final compiled binary uses from the OS that I've built on into this folder, so that in the self-extracting installer we have the right versions of libraries. Maybe that'll make it work.

[hiran]

Do not worry. This is exactly the issue why I could not move on last time.

I think the issue is that the binary is compiled against different versions of libraries than what is here. So my idea is to just copy all the libraries that the final compiled binary uses from the OS that I've built on into this folder, so that in the self-extracting installer we have the right versions of libraries. Maybe that'll make it work.

Good idea, it might work.

I just created a pull request. However I won't merge - somehow I'd like a second pair of eyes on that change.
But once merged, we can work together on the details of the build. There is for sure room for improvements.

[hiran]

I just created a pull request. However I won't merge - somehow I'd like a second pair of eyes on that change.
But once merged, we can work together on the details of the build. There is for sure room for improvements.

Thank you guys for the feedback, I tested the workflow some more and found some improvements.
When merging within my repo I accidentially changed the official one, and now the pull request is closed already - hence taking the discussion here.

From my experiments I found out we did some unusal practice of tagging the Oolite release with 'latest'. Instead, Github automatically keeps a 'latest' flag for the latest release while prereleases do not receive this status. So I thought a bit about the (pre)release naming/tagging.

Looking at previous releases it looks like the Oolite version number was used, plus maybe a letter to distinguish intermediate/unstable releases. Example: 1.80a

Therefore I used the version number found in file src/Cocoa/oolite-version.xcconfig in the workflow, too. But with just that it is possible to have multiple builds using the same version number. To preserve history and have something uniquely addressable, I thought of extending that with the commit hash. But that is barely readable for humans and cannot be sorted in a reasonable way. So I switched to the build number. Not the best, but currently releases are numberd like

Code: Select all

<Oolite version>-<build number>

which can result in something like

Code: Select all

1.91-15

As I want to see builds for feature branches so we can share intermediate development results, changes on branches other than master will result in prereleases numbered as

Code: Select all

<Oolite version>-<branch name>-<build number>

which can result in something like

Code: Select all

1.91-cursor_opacity-16

While mulling all over this, I came across Semantic Versioning which we might want to move into.

Please let me know what you think about it.

[another_commander]

Looking at the commit history, I see this:
"I verified prereleases get created for branches but they do not modify the 'latest' tag, which will still point to the latest release."

The problem would most likely come not from the prereleases originating from branches, but from the actual release that would be published once a commit to master gets made. You need to verify that commits to master do not affect the 1.90 release tag.

[another_commander]

Also, regarding incremental build numbers, we already have this in our nightlies versioning (see Makefile):
VER_GITREV := $(shell git rev-list --count HEAD)

This appends the github incremental commit number to the version, producing something like OoliteInstall-1.91.0.7404-230311-b459e81 (that 7404 is the incremental commit number). We are not using it as part of the filename just yet (only embedded in the installer version string and the watermark appearing on screen when the game is run), but it is there and could easily be used.