Besides the immediate performance improvement, reducing
the frequency of downloads should make spurious
failures (network, rate-limiting...) less bothersome.
`FetchContent` respects existing installs, and downloads and compiles the libs
if they aren't found.
This is admittedly a little finicky, since this ignores the usual `Find*`
modules provided by CMake, requiring a bit of glue on our side.
But, one upside is that this moves that logic from our CI into the build system,
which can thus benefit other downstream users.
This also opens the door to some improvements in upcoming commits.
Doing this with Bison turned out to be much more painful, however, due to
`FindBISON` providing the specific `bison_target` command; thus, it remains
installed externally, so that it can be picked up by `FindBISON`.
This also bumps our CMake version requirement slightly, though it's
possible that older versions keep working, or could be supported with small patches;
however, our CI doesn't provide anything below 3.31, so we can't check.
Note that the DLL name created by CMake with `BUILD_SHARED_LIBS`
has changed from `zlib1.dll` to `z.dll`. This was caused by the
"Continued rewrite of CMake build [Vollstrecker]" from its
changelog <https://zlib.net/ChangeLog.txt>, and has been reported
in <https://github.com/madler/zlib/issues/1181>.
The MinGW package `libz-mingw-w64-dev` still calls it `libz1.dll`.
Windows 2025 no longer has a D:/ drive
<https://github.com/actions/runner-images/issues/12416>
which affects where the cached files go.
This can result in one of two errors in the "Install zlib" step
after restoring from cache:
- file cannot create directory: D:/a/rgbds/rgbds/install_dir/lib.
Maybe need administrative privileges.
- file INSTALL cannot find "C:/a/rgbds/rgbds/zbuild/Release/zlib1.dll":
File exists.
Separate caches per OS should solve this problem.
macOS 10.15 introduced full `std::filesystem::path` support.
Before that our use of it would cause the build to fail.
This was not caught because "-mmacosx-version-min=10.9" was only
being passed to clang++ for release builds.
This passes that flag in a new static CI test build, and introduces
a hack developed by @LIJI32 to silence the availability errors,
since we use features already available in macOS 10.9.
This means we are testing both "vanilla" building,
and building static binaries using the same configuration
as during release, which should help avoiding last-minute
surprises.
Copy CMake-built test executables to test directory
Fixes CI failures on Windows.
CI should also have failed on Unices, but it turns out
we instead merely hit the fallback that the `make` path
relies on (building those executables with `make`),
which fails on Windows since `make` is not set up to
find libpng.
ISSOtm
Rangi
Rangi
JL2210
Eldred Habert