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 noticed a problem with the Windows installer - I will investigate

[mcarans]

@phkb Given this is a fairly large change, please can you check it works for you.

One thing I've noticed with this and older versions like Oolite 1.93.1-kja-sdl3.2 is that speech doesn't work for me on Windows. This is unrelated to this change. I'm guessing it's related to SDL3. With 1.92.1, speech works ok for me on Windows. On Linux, there is no issue with speech.

[oocube]

Looks like there some things we need to check for regularly. I extended
https://wiki.alioth.net/index.php/Common_Testing

[phkb]

How do I add meson to my build environment?
I pulled the PR, tried my normal "make debug=no" which failed and told me I needed to use "make release", which also failed with the error "/bin/bash: line 1: meson: command not found". So I'm assuming meson isn't available yet.

[phkb]

I ran ShellScripts/Windows/install_deps.sh which didn't seem to help.

[phkb]

I notice the install script is failing:

Packages (1) mingw-w64-ucrt-x86_64-sdl3-3.4.2-1

Total Installed Size:  14.31 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                                                                                                                     [####################################################################################################] 100%
(1/1) checking package integrity                                                                                                                                   [####################################################################################################] 100%
(1/1) loading package files                                                                                                                                        [####################################################################################################] 100%
(1/1) checking for file conflicts                                                                                                                                  [####################################################################################################] 100%
(1/1) checking available disk space                                                                                                                                [####################################################################################################] 100%
:: Processing package changes...
(1/1) reinstalling mingw-w64-ucrt-x86_64-sdl3                                                                                                                      [####################################################################################################] 100%
ShellScripts/Windows/install_deps.sh: line 47: cd: ../../build/packages: No such file or directory
Installing common libraries
Installing spidermonkey package
❌ No file matching mingw-w64-ucrt-x86_64-spidermonkey*any.pkg.tar.zst found!

I'm running the command from root level of the source tree, which is where I would normally run the "make" process. Is that correct?

[mcarans]

I notice the install script is failing:

Packages (1) mingw-w64-ucrt-x86_64-sdl3-3.4.2-1

Total Installed Size:  14.31 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                                                                                                                     [####################################################################################################] 100%
(1/1) checking package integrity                                                                                                                                   [####################################################################################################] 100%
(1/1) loading package files                                                                                                                                        [####################################################################################################] 100%
(1/1) checking for file conflicts                                                                                                                                  [####################################################################################################] 100%
(1/1) checking available disk space                                                                                                                                [####################################################################################################] 100%
:: Processing package changes...
(1/1) reinstalling mingw-w64-ucrt-x86_64-sdl3                                                                                                                      [####################################################################################################] 100%
ShellScripts/Windows/install_deps.sh: line 47: cd: ../../build/packages: No such file or directory
Installing common libraries
Installing spidermonkey package
❌ No file matching mingw-w64-ucrt-x86_64-spidermonkey*any.pkg.tar.zst found!

I'm running the command from root level of the source tree, which is where I would normally run the "make" process. Is that correct?

It's probably simplest to just run setup.cmd from a command prompt to create a fresh up to date environment. setup.cmd installs msys2 and downloads latest dependencies which are then installed by install_deps.sh (which is called by setup.cmd).

Alternatively, you need to download the dependencies manually into build/packages if you just want to run install_deps.sh from an existing msys2: https://github.com/OoliteProject/oolite_windeps_build/releases/tag/0.1.4. Prior to running install_deps.sh, it is a good idea to run pacman -Syu --noconfirm a couple of times to ensure msys2 is up to date. The script will install meson and ninja: pacboy -S meson --noconfirm and pacboy -S ninja --noconfirm.

[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?