WIP: external_deps, use CMake when packages do, update versions

[illwieckz]

This is WIP, current external_deps build status:

system	deps build
linux-amd64-default	✅️
linux-arm64-default	✅️
linux-i686-default	✅️
linux-armhf-default	✅️
windows-amd64-mingw	✅️
windows-i686-mingw	✅️ Buster ❌️ GLEW Noble
windows-amd64-msvc	✅️
windows-i686-msvc	✅️
macos-amd64-default	✅️

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

What this PR does:

• Use CMake when packages provide a CMakeLists.txt file
• Factorize much code
• Make a nice list of package base url, so it's easy to click all of them and check for new versions
• Update package versions

[illwieckz]

For windows-i686-mingw I get this with GLEW:

i686-w64-mingw32-ld -nostdlib -shared -soname libglew32.dll --out-implib lib/libglew32.dll.a
     -o lib/glew32.dll tmp/linux-mingw32/default/shared/glew.o
     -Lexternal_deps/build-windows-i686-mingw_10/prefix/lib -L/usr/i686-w64-mingw32/lib
     -lopengl32 -lgdi32 -luser32 -lkernel32 
i686-w64-mingw32-ld: tmp/linux-mingw32/default/shared/glew.o:glew.c:(.text+0x141ab):
 undefined reference to `strlen'

Everything else build.

[illwieckz]

For windows-amd64-msvc I get this with Vorbis:

[ 84%] Linking C shared library libvorbis.dll
/usr/bin/x86_64-w64-mingw32-ld:
 external_deps/build-windows-amd64-msvc_10/vorbis/libvorbis-1.3.7/win32/vorbis.def:3: syntax error
/usr/bin/x86_64-w64-mingw32-ld:
 external_deps/build-windows-amd64-msvc_10/vorbis/libvorbis-1.3.7/win32/vorbis.def: file format not recognized; treating as linker script
/usr/bin/x86_64-w64-mingw32-ld:
 external_deps/build-windows-amd64-msvc_10/vorbis/libvorbis-1.3.7/win32/vorbis.def:2: syntax error

Everything else build.

[illwieckz]

• OGG has a CMakeLists.txt file but no install target, so I returned back to configure for this one.
• Opus requires at least CMake 3.16.

[illwieckz]

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

opus/opus-1.5.2/silk/x86/NSQ_del_dec_avx2.c:959:43: warning: implicit declaration of function '_mm_loadu_si64'; did you mean '_mm_loadu_si32'? [-Wimplicit-function-declaration]
         __m256i x = _mm256_cvtepi16_epi64(_mm_loadu_si64(&x16[i]));
                                           ^~~~~~~~~~~~~~
                                           _mm_loadu_si32

Debian Buster provides GCC 8, but GCC 11.3 or GCC 12 may be required:
https://stackoverflow.com/questions/72837929/mm-loadu-si32-not-recognized-by-gcc-on-ubuntu

[illwieckz]

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.

[illwieckz]

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

[illwieckz]

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.

[illwieckz]

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.

[illwieckz]

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.

[illwieckz]

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…

[illwieckz]

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…

[slipher]

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