[proposal] Remove all usages of `check_symbol_exists`

[jeremyong]

I may be missing something and am open to any explanation for the rationale behind check_symbol_exists, but as it stands I'm not sure I understand the value proposition.

The usage of check_symbol_exists essentially frontloads compiler validation of the existence of various symbols which results in a very slow CMake generation time for the project. Any changes to configuration or build type causes all the checks to run again, making for a painful iteration process. Why couldn't these errors simply occur during the course of actual compilation? As it is, CMake itself will run on a single core, compiling test programs for each individual header/feature/symbol-check every time configuration changes, which seems extremely expensive.

[icculus]

We kinda need a bunch of these, as they decide things about what we compile.

[madebr]

I think the only way to fix this now is cache the results ourselves. Like we do for MSVC now, but generated during first configuration.

The main issue here is that CMake is synchronous, single-threaded and suffers from a high ipc overhead. I created a proof of concept that, using undefined behavior, does all tests in parallel (it does not work with clang). So the many check_symbol_exists tests can be fast, we just need some support from the compiler.

[jeremyong]

Sorry for the late response. My suggestion would be to adopt a toolchain-like concept to drive the configuration. The usual way to do something like this is to adopt a presets file (https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html) which can be shared and passed to cmake on the command line to drive the compilation for a given compiler.

This isn't useful for people that use toolchains not known to SDL (weird compilers or platforms), so I would suggest a tool to generate such a presets file using the checks as used currently during the generation phase. This could run implicitly if no preset is provided using the actively configured kit for example.

[madebr]

We recently did a similar thing in SDL3 that predefines variables for MSVC only.

Using presets would be another solution to this problem. (I had a bad IDE experience with presets earlier that caused me to avoid them)

We could for example define a linux-glibc, windows-msvc and macos15 preset.

[batuhanbozyel]

@madebr do you have a version of predefines for MacOS - Clang as well, possibly ARM architecture? This preseeding already speeds up project generation around 10x for Windows/MSVC version of the project since almost all the time is spent on SDL3's compiler checks

[madebr]

@madebr do you have a version of predefines for MacOS - Clang as well, possibly ARM architecture? This preseeding already speeds up project generation around 10x for Windows/MSVC version of the project since almost all the time is spent on SDL3's compiler checks

No. I don't own any Apple devices. Feel free to provide ones. But please make sure it properly handles older macosx vs newer macos, apple-clang vs clang, etc...

[icculus]

I'll dig up the macOS specifics.