When building newer Opus on Debian buster (the distro we use for our releases), I get this: […]

Telling Opus to not assume more than SSE2 fixed that.

So, the MinGW GLEW and MSVC Vorbis errors are the only ones.

So the Vorbis build error is actually a bug:

• [libvorbis] Build error microsoft/vcpkg#22990
• [libvorbis] Fix mingw-dynamic, modernize port microsoft/vcpkg#23761

I added a workaround.

I don't get why I get that GLEW build error with MinGW, the build function has not been modified, and the version has not been updated.

I don't get why I get that GLEW build error with MinGW, the build function has not been modified, and the version has not been updated.

Also the code is the same for both windows-amd64-msvc, windows-i686-msvc, windows-amd64-mingw and windows-i686-mingw, but it only fails with windows-i686-mingw… That doesn't make sense.

So, I don't know what happened, now I don't reproduce the MinGW GLEW error… Maybe I gorgot to prune the prefix folder and some stray files messed-up…

Ah, I now see something: I reproduce the bug with MinGW from Ubuntu 24.04 Noble, not with MinGW from Debian 10 Buster. So, since we produce release builds with Debian Buster, it's not a big problem, but it should be fixed for the future…

What's the purpose of migrating things to build with CMake?

So with this a static build for linux-amd64 completes and runs.

So with this a static build for linux-amd64 completes and runs.

Huh? It worked before, so I have a hard time believing that is suddenly necessary to change the build system of 8 packages.

I never said this is a response to “What's the purpose of migrating things to build with CMake?”, I'm just reporting the status of me testing that branch. I said in first post:

I haven't tested if the engine builds and runs properly with those.

So now I'm running those tests.

What's the motivation behind this change?

Purposes:

1. Update packages to latest versions,
2. Update packages build options for latest versions (for example curl adds protocols, so we have to disable them),
3. Mutualize cmake/configure code as generic reused functions and avoid copy/paste boilerplate,
4. Rely on CMake as much as possible to make it easy to spot new CMake build options to disable them and other changes.

When using configure it is hard to compare the list of already used options with the new options, one has to read configure's whole output and compare with what's currently used. On the contrary with cmake, one just runs the existing command, then go to the build dir and run ccmake, and see what's enabled and should not, and report the difference to the build script.

windows-amd64-mingw and windows-i686-mingw engine both build and run.

For some reasons libpng now provides png.framework on macOS and the engine build looks for it instead of the static library (even with USE_STATIC_LIBS), so I made generic the copy of any *.framework from deps. I don't know if we prefer static linking or dynamic linking on macOS, static linking allows further LTO optimizations so we may prefer that.

linux-i686-default and macos-amd64-default engine both build and run.