Switch to Meson instead of GNUmakefile

[mcarans]

Meson (using ninja backend) is faster
Meson integrates with IDEs (tested with CLion)
It can generate XCode projects apparently
No need to source GNUstep.sh with all its obscure magic - all required flags are in the build
Top level Makefile remains (although refactored and calls meson)
Also added to manifest:

echo "    git_remote_url = \"$(git config --get remote.origin.url)\";"
echo "    git_commit_hash = \"$(git rev-parse HEAD)\";"

Fixes #577

[mcarans]

I've debugged the Windows sound issue - requires fixing pcaudiolib due to SDL3 change:

struct audio_object *
create_xaudio2_object(const char *device,
                      const char *application_name,
                      const char *description)
{
	HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
	if (FAILED(hr) && hr != (HRESULT)0x80010106) {
		return NULL;
	}
...

[phkb]

OK, after some fiddling around, I've got the build working. A couple of points:

1. Running the exe opens a command window first, and then the splash screen appears and the game opens. The command window remains open while the app is running, and closes when the app does. Is that required? It certainly didn't happen before.
2. The app doesn't have the Oolite icon

[mcarans]

OK, after some fiddling around, I've got the build working. A couple of points:

1. Running the exe opens a command window first, and then the splash screen appears and the game opens. The command window remains open while the app is running, and closes when the app does. Is that required? It certainly didn't happen before.

2. The app doesn't have the Oolite icon

From what I have found, 1 is fixed by adding this: https://mesonbuild.com/Reference-manual_functions_executable.html#executable_win_subsystem

like this in src/meson.build:

oolite_bin = executable(
'oolite',
my_sources,
include_directories: my_includes,
dependencies: oolite_deps,
win_subsystem: 'windows',
link_args: extra_link_args,
build_rpath: '$ORIGIN',
install_rpath: '$ORIGIN',
install: true,
)

I just checked in that fix but haven't had a chance to test yet. Maybe that will also fix the icon?

[kanthoney]

The ShellScripts/Windows/install_deps.sh script seems to be broken. It fails to install spidermonkey, and then crashes leaving meson uninstalled. On my machine, if I run pacboy -S meson manually it then builds fine, but I think that's because I've already got spidermonkey installed. I can't work out where it's supposed to be installed from if you're a new Windows developer

[mcarans]

@kanthoney Does what I suggested here help? #665 (comment). If not, I'll have to investigate what has happened.

[phkb]

From what I have found, 1 is fixed by adding this: https://mesonbuild.com/Reference-manual_functions_executable.html#executable_win_subsystem
...
I just checked in that fix but haven't had a chance to test yet. Maybe that will also fix the icon?

Point 1 appears to be fixed. Point 2 remains.

[mcarans]

@phkb I had forgotten to compile and add the OOResourcesWin.rc file which adds the icon on Windows. Point 2 should now be fixed.

[phkb]

Confirmed icon is now being applied to the exe.

With the Windows installer options, they work OK, but the file names are missing the version number. For instance, for the deployment build, the filename is "OoliteInstall--win.exe", and the test release is "OoliteInstall--win-text.exe"

[mcarans]

Confirmed icon is now being applied to the exe.

With the Windows installer options, they work OK, but the file names are missing the version number. For instance, for the deployment build, the filename is "OoliteInstall--win.exe", and the test release is "OoliteInstall--win-text.exe"

Where do you see that? When I download one of the Windows ones from here and open the zip, I see a version number:
https://github.com/OoliteProject/oolite/actions/runs/27109053079?pr=665

eg.

[phkb]

Here:

Should I be looking somewhere else for the final build files?

[mcarans]

Here:

Should I be looking somewhere else for the final build files?

I see - this is a local build. The process for getting the version is unchanged and I'm wondering if it worked before the meson changes. Can you confirm if you got proper version numbers for local builds before?

[phkb]

For v1.92, I ran the NSIS script file manually in NSIS, and then manually named the output file. I haven't built the Windows packages via the "make" process locally before.

[phkb]

It's also not a showstopper. The files themselves all work fine. If it came to an official release, and we had to rely on locally built files, it's really no effort to rename them. I just thought it was odd the version number wasn't already there, when it clearly is supposed to be there.

[mcarans]

@oocube Do you know if version numbers work for local builds on Windows in master?

[oocube]

@oocube Do you know if version numbers work for local builds on Windows in master?

I never tested local builds, let alone that payware operating system.
The theory I followed was to use gitversion for semver version numbers, which definitely works in Github and fallback to previous behaviour for local builds. I'd have expected the old clumsy version number to be applied but having nothing is indeed weird.

Is the version number missing everywhere or just on the filename?

[phkb]

Just on the filename

[oocube]

Just on the filename

Then this is a hint that version calculation in the background still works but is communicated wrongly to NSIS.

[kanthoney]

@mcarans Can confirm that running the ShellScripts\Windows\setup.cmd command and installing from scratch works fine

[mcarans]

@kanthoney Thanks for testing setup.cmd. I have made a ticket to provide an upgrade step for existing MSYS2 installs. #668

[mcarans]

@oocube @phkb @kanthoney Just tested Linux appimage local build and it has version. It's a Windows specific issue. I've made a ticket for it: #669. I suspect it preexists this PR, so if you're all happy with this, please can someone approve it so I can merge.

[mcarans]

@oocube @phkb Seems I need one of you to approve this too to be able to merge.

[oocube]

I tested oolite_dev-1.93.1-PullRequest665.204-x86_64.AppImage and it's looking good.