Solve host system and target system detection once for all.
Fix:
- So many warnings, failed to fully compile, and missing GTK GL Extension #207
What was expected to be an easy task (we already build GtkGLExt as a builtin for macOS) turned into a nightmare and a 12+ hours work. 💀️
Actually this work being done means I'm able to produce Windows NetRadiant builds anew… I discovered the old Windows VM I was keeping safe for building NetRadiant (without any MSYS2 regressions) could not build build GtkGLExt. And I could not install the packages required by GtkGLExt without updating MSYS2 and then bringing other MSYS2 bugs I had to fix.
Here is me running a release-like build of NetRadiant on Windows 11, rebuilt yesterday with this branch:
My workflow relies on network shares (every build machines share the same folders, with unified commands). But executing within MSYS2 a program stored on a network share on Windows 11 makes it impossible to delete that executable until the file server is restarted AND the network share is disconnected and reconnected. But then the configure-based build (used by GtkGLExt) runs all its detection tests by crafting a temporary conftest.exe binary for every test in the source directory, overwriting that conftest.exe is overwritten after each test. That temporary program path cannot be redirected to some random temporary directory, so the first test passing makes all remaining tests failing, requiring the equivalent of a reboot of both the file server and the build machine client on every configure step (one can just restart the services and reopen sessions but you get the idea) while the whole configure run has to be restarted from scratch after every test, making it impossible to finish…
So that netradiant work has been crazy as I not only had to create a special GtkGLExt branch to get it build for windows again, implemented workarounds for converting windows paths to MSYS paths in cmake for configure subprojects, but also implement out-of-source build in GtkGLExt configure and implement subproject build in temp directory in CMake to workaround the MSYS2 bug… what a mess.
If you build on network shares, the easy-builder command should instead be:
EP_BUILD_DIR=/tmp/netradiant ./easy-builderI updated the MSYS2 package installation instructions for Windows on the README. This now recommends the UCRT64 flavour (to be built from the MSYS2 UCRT64 shell) and requires more packages to be installed (to build the GtkGLExt builtin).
Like macOS, the GtkGLExt build for Windows now relies on a special windows branch hosted there:
Having a branch for each platform with their specific fixes likely breaking other platforms is the less costly solution. Given I'm the last people on Earth to actually maintain GtkGLExt, I will likely not spend any time to make a branch working everywhere.
This windows GtkGLExt branch may be force-pushed until this NetRadiant branch is merged.
I will likely have to fix the macOS build as well to fit the changes I did in the NetRadiant repository (I modified the build workflow…).
I added some commits to make heretic2, quake2 and quake3 tools build again. They're all the exact same fix reported to the different trees. I haven't tested that fix yet, one can verify if it works by building a map on Windows with q3map2 built from this branch.
This now uses the Yokai CMake framework. This is a framework I wrote for the Dæmon engine with future usage in NetRadiant in mind. This is meant to solve pitfals of CMake in detecting compilers, host and target systems, etc.
Work in progress documentation of Yokai can be found there: https://wiki.unvanquished.net/wiki/Tools/Yokai
Here are the detailed commit messages:
cmake: integrate the Yokai framework
Solve host system and target system detection once for all.
The upstream is maintained there:
cmake: rework the GtkGLExt builtins build
- Make possible to build GtkGLExt for Windows.
- Make possible to configure and build GtkGLExt outside of source to workaround the MSYS2 bug making impossible to delete an executable on a network share after execution (all build tests are done by replacing the same conftest.exe binary with a new one, in the source folder…).
- Add a EP_BUILD_DIR option to give an arbitrary build directory to let the user using network drives to build external projects (here: GtkGLExt) on a non-network directory to workaround that same MSYS2 bug.
- Translate or reconstruct MSYS2 paths to avoid CMake passing paths like C:\msys64\usr* to configure what would then be wrongly translated to /msys64/usr/* instead of /usr/* and fail.
- Use autoreconf instead of autogen.sh.
- Rework the compiler flags enablement.
- Add some compiler flags for compatibility purpose.
- Use a specially crafted Windows branch of GtkGLExt, like macOS.
cmake: rework the GTK selection and builtins enablement
- Only enable Radiant builtins when Radiant is built.
- Only set GTK2 when Radiant is built.
- Enable GtkGLExt builtin only on GTK2.
- Enable GtkGLExt builtin for Windows, MSYS2 dropped it.
easy-builder: rework and make it more robust for GtkGLExt building on MSYS2
- Unset MSYS2_ARG_CONV_EXCL (if set) in case the user changed the default, the paths used by CMake and Configure commands used for building GtkGLExt are very messy, but we better deal with a consistent mess.
- Rework the jobs enablement to set it for all CMake calls once for all.
- Rework the CMake invocations to not call Make directly.
- Now make CMake use -S and -B for source and build directories.
heretic2: fix threads on Windows quake2: fix threads on Windows quake3: fix threads on Windows
Fix:
tools/quake3/common/threads.c:207:33: error: passing argument 6 of 'CreateThread' from incompatible pointer type [-Winc
ompatible-pointer-types]
207 | &threadid[i] );
| ^~~~~~~~~~~~
| |
| int *
