feat(compat.sdl3): SDL3 3.4.2, built from source

[Sunrisepeak]

The last of vulkan-rt's dependencies, and the one that could not ride along in #370: 266 sources, three platforms, and a config header that has to be generated. Shape E, and a sibling to compat.sdl2 rather than its replacement — SDL2 and SDL3 are different APIs with different sonames, and projects migrate on their own schedule.

Two things are easier than they were for SDL2

Both measured, not assumed:

• No repacked tarball. SDL2's entry has to point at an xlings-res re-host because the upstream archive carries symlinks that break the windows runner. SDL3's carries none — tar tvzf | grep -c '^l' is 0 — so GLOBAL points straight at GitHub.
• The config dispatcher is upstream's. include/build_config/SDL_build_config.h already selects _windows.h / _macos.h by platform, and both of those are checked in. Only linux falls through to SDL_build_config_minimal.h, which has no video driver at all. So exactly one config is generated, and only linux uses it.

The config may only claim what this index packages

That is a rule, not a preference. CMake probes the machine it runs on, so anything the host happens to have gets switched on and then fails to compile here. Three were found by failing builds:

switched off	why
SDL_X11_XSCRNSAVER	src/video/x11/SDL_x11dyn.h:69: fatal error: X11/extensions/scrnsaver.h: No such file or directory — there is no compat.xss
SDL_LIBTHAI	the Thai line-breaker the X11 message-box toolkit uses
SDL_HIDAPI_LIBUSB	hidapi's libusb backend

XTEST and XSYNC are off pre-emptively for the same reason.

What remains is checkable rather than hopeful: every library the finished config says it will dlopen must have a package here. That list is seven, and it matches linux.deps exactly:

libfribidi.so.0  compat.fribidi     libX11.so.6      compat.x11
libXcursor.so.1  compat.xcursor     libXext.so.6     compat.xext
libXfixes.so.3   compat.xfixes      libXi.so.6       compat.xi
libXrandr.so.2   compat.xrandr

Because the X11 driver is x11(dynamic), those are compile-time headers only — the package links against none of them.

The config was also generated with this index's toolchain and the index's own X11 headers, which is not a formality: mcpp's gcc has its own sysroot and cannot see /usr/include, so without them SDL's check fails and configure aborts outright. compat.curl records what the shortcut costs — a config generated with the host cc once asserted that ssize_t does not exist.

The source list is CMake's own answer

Not a reading of CMakeLists.txt. After configuring, the objects CMake decided to build were read back out of CMakeFiles/SDL3-static.dir/build.make and mapped to directories: 266 sources → 73 directories taken whole + exactly one taken in part. That one is src/core/linux, minus the six dbus/IME files (SDL_dbus.c, SDL_fcitx.c, SDL_ibus.c, SDL_ime.c, SDL_progressbar.c, SDL_system_theme.c) — the same set compat.sdl2 omits, and for the same reason: they are not guarded internally, they simply fail without dbus-1 headers.

Everything else is a directory glob, which works because SDL compiles unselected backends into empty translation units — render/direct3d12 and render/ps2 are in the common list and contribute nothing on linux.

macOS and Windows

They do not use the generated config, so their lists are derived from what the checked-in configs switch on (COREAUDIO / IOKIT / MFI / COCOA / METAL / GPU_METAL … and WASAPI / DSOUND / DINPUT / XINPUT / WGI / D3D11 / D3D12 …).

The non-obvious one is windows: SDL_THREAD_GENERIC_COND_SUFFIX and SDL_THREAD_GENERIC_RWLOCK_SUFFIX mean the windows backend implements condition variables and rwlocks by falling back to the generic ones, so thread/generic/SDL_syscond.c and SDL_sysrwlock.c must be linked alongside thread/windows/*. Only those two — the other four generic files share basenames with their windows twins, and taking the directory whole would compile two definitions of the same functions.

The test runs headless on all three platforms

It forces SDL's dummy video driver, so it exercises the real video subsystem without a display server:

• header and runtime version agree (one tarball, not two), and equal 3.4.2
• the compiled-in driver list contains dummy and offscreen — a config that fell through to SDL_build_config_minimal.h has neither, which is exactly the failure mode a "it compiled" test would miss
• the dummy driver initialises, becomes the current driver, and produces a 320×240 window with a surface of that size that can be filled
• SDL_GetTicks advances across a delay

Verified

leg	result
linux · gcc 16.1.0	267 units compiled, test passes
linux · llvm 22.1.8	267 units compiled, binary runs

⚠️ macOS and Windows are derived as described above and confirmed by CI, not locally — there is no way to compile either from this machine. If a platform list is wrong, this is where it shows.

CN mirror at gitcode.com/mcpp-res/sdl3, byte-identical to upstream (verified by downloading it back and comparing sha256).