Detect and run modern installations

[another_commander]

But it could answer the next question I was going to shoot: Where would I find the developer version's debug.oxp?

It is at https://github.com/OoliteProject/oolite ... /Debug.oxp

[mcarans]

The extract worked for me. Make sure you issue 2 commands - extract then cat:

Ok, that explains. This way I get the full appimage extracted - it takes more than 200 MB disk space just to find the version number. I hope we can improve on that.

It is possible to avoid extraction and do it in one line but you have to have unsquashfs which requires installing squashfs-tools:

Code: Select all

1 > unsquashfs -o $(./Oolite_1.93.0.7774-260215-82f9ce6-x86_64.appimage --appimage-offset) -cat ./Oolite_1.93.0.7774-260215-82f9ce6-x86_64.appimage /usr/bin/Resources/manifest.plist
{
        title = "Oolite core";
        identifier = "org.oolite.oolite";

        version = "1.93";
        required_oolite_version = "1.93";

        license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
        author = "Giles Williams, Jens Ayton and contributors";
        information_url = "https://oolite.space/";
}

You could test for the existence of unsquashfs and use it if available, falling back on extraction if not, or just tell appimage users to install squashfs-tools (it's the same package name on Debian, Fedora and Arch).

[hiran]

But it could answer the next question I was going to shoot: Where would I find the developer version's debug.oxp?

It is at https://github.com/OoliteProject/oolite ... /Debug.oxp

I'm afraid with that location any installation is a debug build.

Maybe I should have asked differently:

How can i differentiate a debug build of appimage(Oolite) from non-debug build of appimage(Oolite)?

[another_commander]

How can i differentiate a debug build of appimage(Oolite) from non-debug build of appimage(Oolite)?

One way to do it could be to check the hash of the main executable and compare it to the corresponding known hashes.

For example, get the SHA1 of the known debug executable and compare it to the calculated SHA1 of the executable you are investigating.

[hiran]

How can i differentiate a debug build of appimage(Oolite) from non-debug build of appimage(Oolite)?

One way to do it could be to check the hash of the main executable and compare it to the corresponding known hashes.

For example, get the SHA1 of the known debug executable and compare it to the calculated SHA1 of the executable you are investigating.

I do not like this. The hash should be different for every OS and every release we do. A change to Oolite would then require a new version of OoliteStarter to be rolled out just so the hash is contained.

The exact build and version information is the only data I need, and having to extract the packages, knowing the internal structures and hash the content sounds really desperate.

What is the problem with a simple command line option "-version" that prints the exact version string and exits?
I would have added that command line flag long ago if only I knew where Oolite internally stores/fetches it's version number.

[another_commander]

What is the problem with a simple command line option "-version" that prints the exact version string and exits?
I would have added that command line flag long ago if only I knew where Oolite internally stores/fetches it's version number.

The problem is that it is more complicated than it looks. Additionally, the Windows Oolite does not output to console but to a file because SDL redirects stdout and stderr. This is problematic for the MS Store version because these files get generated inside the application folder, which by default is read-only for packages. That would cause errors, potentially fatal if attempted. We will have to find a way to stop the redirect from happening. There is the SDL_STDIO_REDIRECT env variable but then we'll have to find a way to set it up upon installation of the package. As you can see it is not just a matter of adding one more cmd line argument.

Having said all that, I already have some functional code that imports the full github version in the Oolite binary and added this to the -help command output. Further to that, I have added the -version parameter that just outputs the full version string and exits. But that's being only half way through. Will commit after I've done some more testing with it.

[hiran]

If SDL redirects all output, this for sure only happens once SDL gets activated. Until then Oolite should behave like any other application.
So all we would have to ensure is that the commandline - at least the -version option gets processed before SDL is activated and we should be good?

[another_commander]

No it doesn't work like that unfortunately. Everything environment related gets set up via SDL's main before our own main function starts.

The -version parameter I have implemented is all done before any official SDL initialization, but still the redirect occurs.

[mcarans]

In the post build, we could generate a version file. Already in the generated build folder, there is a file version.mk that looks like this:

Code: Select all

VERSION=1.92.1
VER_MAJ=1
VER_MIN=92
VER_REV=1
VER_DATE=260222
VER_GITREV=7792
VER_GITHASH=db22c95
VER=1.92.1.7792-260222-db22c95
BUILDTIME=2026.02.22 18:14

It is created by ShellScripts/common/get_version.sh which could be augmented to capture the type of build.

We could capture whether it's release-deployment (DEPLOYMENT_RELEASE_CONFIGURATION=yes), release or release-snapshot (SNAPSHOT_BUILD=yes) and output an extra line like:

Code: Select all

BUILD_TYPE=release-deployment

Then include that file in the NSIS, appimage etc.

Would that work?

[hiran]

In the post build, we could generate a version file. Already in the generated build folder, there is a file version.mk that looks like this:

Code: Select all

VERSION=1.92.1
VER_MAJ=1
VER_MIN=92
VER_REV=1
VER_DATE=260222
VER_GITREV=7792
VER_GITHASH=db22c95
VER=1.92.1.7792-260222-db22c95
BUILDTIME=2026.02.22 18:14

It is created by ShellScripts/common/get_version.sh which could be augmented to capture the type of build.

We could capture whether it's release-deployment (DEPLOYMENT_RELEASE_CONFIGURATION=yes), release or release-snapshot (SNAPSHOT_BUILD=yes) and output an extra line like:

Code: Select all

BUILD_TYPE=release-deployment

Would that work?

- You mentioned that the Linux packages (Appimage, Flatpak) would run a shell script. Can that one be made to print the build type and version number (VER)? It would prevent having to extract the packages at runtime.
- For classic builds that get distributed in whatever means it will help to have the full version number in manifest.plist. Maybe the build type can be added to the plist as well.

Both the above points will make OoliteStarter tremendously simpler and more maintainable while not requiring any information to be printed by Oolite itself.

Remains one thing: AFAIK the debug build needs the debug oxp to do whatever. The presence of the debug oxp was my test for a debug build in the past. Now that this OXP is no longer contained, does the debug build still work with the debug console?

[mcarans]

In the post build, we could generate a version file. Already in the generated build folder, there is a file version.mk that looks like this:

Code: Select all

VERSION=1.92.1
VER_MAJ=1
VER_MIN=92
VER_REV=1
VER_DATE=260222
VER_GITREV=7792
VER_GITHASH=db22c95
VER=1.92.1.7792-260222-db22c95
BUILDTIME=2026.02.22 18:14

It is created by ShellScripts/common/get_version.sh which could be augmented to capture the type of build.

We could capture whether it's release-deployment (DEPLOYMENT_RELEASE_CONFIGURATION=yes), release or release-snapshot (SNAPSHOT_BUILD=yes) and output an extra line like:

Code: Select all

BUILD_TYPE=release-deployment

Would that work?

- You mentioned that the Linux packages (Appimage, Flatpak) would run a shell script. Can that one be made to print the build type and version number (VER)? It would prevent having to extract the packages at runtime.
- For classic builds that get distributed in whatever means it will help to have the full version number in manifest.plist. Maybe the build type can be added to the plist as well.

Both the above points will make OoliteStarter tremendously simpler and more maintainable while not requiring any information to be printed by Oolite itself.

Remains one thing: AFAIK the debug build needs the debug oxp to do whatever. The presence of the debug oxp was my test for a debug build in the past. Now that this OXP is no longer contained, does the debug build still work with the debug console?

You've found the root problem. The appimage build does not copy the addons folder for test builds which it should. Flatpak only builds release-deployment so it isn't an issue there. I need to make a fix.

[hiran]

No it doesn't work like that unfortunately. Everything environment related gets set up via SDL's main before our own main function starts.

The -version parameter I have implemented is all done before any official SDL initialization, but still the redirect occurs.

Whoa! I asked Google Gemini " Why does SDL redirect output to stdout and stderr? ", and here is it's answer:

It’s a classic "gotcha" for developers using SDL (Simple DirectMedia Layer), especially on Windows. If you’ve ever wondered why your printf statements or std::cout logs suddenly vanished into the void, you’ve felt the sting of SDL’s legacy behavior.

Here is the breakdown of why this happens and how it works.

1. The Historical "Why" (Windows Win32)

The primary reason is historical and platform-specific. On Windows, a standard GUI application (subsystem:windows) does not have a console attached to it by default.

In the early days of SDL, if a developer used printf, the output would simply disappear because there was no terminal to catch it. To be helpful, SDL’s creators decided to redirect stdout and stderr to local files—stdout.txt and stderr.txt—so developers could actually read their logs after the program closed.

2. How SDL Performs the Redirect

When you include SDL.h, it often pulls in a header that redefines your main function to SDL_main. During the initialization process (specifically inside the SDL_main entry point logic), SDL performs a stream redirection.

Mathematically, you can think of it as a file descriptor mapping:

Standard: fd(1)→Console STDOUT

SDL Redirect: fd(1)→stdout.txt

3. The Modern Context

In SDL2 and SDL3, this behavior is much less aggressive than it was in the original SDL 1.2.

SDL 1.2: Almost always forced the creation of .txt files on Windows.

SDL 2.0+: Generally respects the environment. If you run your app from a console or compile it as a console application, it usually leaves your streams alone. However, if it detects it's in a pure "Windows App" mode, it may still trigger the redirection to ensure errors are captured somewhere.

How to Prevent It

If you want to keep your output in the terminal and stop SDL from hijacking your streams, you have a few options:

Use SDL_Log: Instead of printf, use SDL's built-in logging system. It is designed to be cross-platform and handles the routing to the appropriate debug console or terminal automatically.

Define NO_STDIO_REDIRECT: If you are building from source or using specific wrappers, defining this macro before including SDL headers can sometimes disable the behavior.

Link as a Console App: In Visual Studio, change your Linker settings:

System -> Subsystem -> Console (/SUBSYSTEM:CONSOLE)

This forces Windows to provide a terminal, which usually keeps SDL from feeling the need to redirect to a file.

[another_commander]

I have managed to pass the full Oolite version to the generated manifest.plist file in Resources. This is what that manifest file looks like now:

Code: Select all

{
	title = "Oolite core";
	identifier = "org.oolite.oolite";
	
	version = "1.93";
	required_oolite_version = "1.93";
	version_full = "1.93.0.7775-260223-e400ac6";    // <------ this is the newly inserted line
	
	license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
	author = "Giles Williams, Jens Ayton and contributors";
	information_url = "https://oolite.space/";
}

@hiran, is that acceptable for your purposes? I think it's the best shot we've got so far. The full version string now appears both in the help text and in this manifest so it should be possible to both read it on-screen and extract it for further processing from external utilities.

[mcarans]

I have managed to pass the full Oolite version to the generated manifest.plist file in Resources. This is what that manifest file looks like now:

Code: Select all

{
	title = "Oolite core";
	identifier = "org.oolite.oolite";
	
	version = "1.93";
	required_oolite_version = "1.93";
	version_full = "1.93.0.7775-260223-e400ac6";    // <------ this is the newly inserted line
	
	license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
	author = "Giles Williams, Jens Ayton and contributors";
	information_url = "https://oolite.space/";
}

@hiran, is that acceptable for your purposes? I think it's the best solution we've got so far. The full version string now appears both in the help text and in this manifest so it should be possible to both read it on-screen and extract it for further processing from external utilities.

Is this manifest used by Oolite itself or only by external utilities? I can see it generated in the make postamble and wondered if Oolite reads values from it.

We could add DEPLOYMENT_RELEASE_CONFIGURATION which can be yes or no. Where it is no, it means that there is a Basic-debug.oxp. Alternatively, we could put the release type like dev or test.

I had been experimenting with including a text file OOLITE_VERSION.txt in the build that would contain:
OOLITE_VERSION=1.92.1.7794-260223-0e2a2d2
BUILDTIME=2026.02.23 20:24
DEPLOYMENT=no

I could then cat that file in the Linux startup script if the user supplies an argument "packageinfo" eg.

Code: Select all

> ./Oolite_test_1.92.1.7794-260223-0e2a2d2-x86_64.AppImage packageinfo
OOLITE_VERSION=1.92.1.7794-260223-0e2a2d2
BUILDTIME=2026.02.23 20:24
DEPLOYMENT=no

I could cat the manifest instead, but just want to check where it is used. For example, if it is not used by Obj C, it makes less sense to use a plist format.

[hiran]

I have managed to pass the full Oolite version to the generated manifest.plist file in Resources. This is what that manifest file looks like now:

Code: Select all

{
	title = "Oolite core";
	identifier = "org.oolite.oolite";
	
	version = "1.93";
	required_oolite_version = "1.93";
	version_full = "1.93.0.7775-260223-e400ac6";    // <------ this is the newly inserted line
	
	license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
	author = "Giles Williams, Jens Ayton and contributors";
	information_url = "https://oolite.space/";
}

@hiran, is that acceptable for your purposes? I think it's the best shot we've got so far. The full version string now appears both in the help text and in this manifest so it should be possible to both read it on-screen and extract it for further processing from external utilities.

Of course this solution is so much better than what we currently have yet still less capable than where we used to be with classic builds.

The full version used to be in 'version'. Why do we need to distinguish a short and a full version at all? Little impact you might not see: The code that parses manifest.plist treats Oolite just like any other expansion. The key 'version' is mandatory and 'version_full key' is not defined at https://wiki.alioth.net/index.php/Manifest.plist

Why the hesitation about showing the full version? It allows users to easily compare and see which of two builds is newer. This helps everybody when reporting bugs or debugging.