libsdl-org
Update CMake support
@madebr mentioned that he wanted to do a large rewrite of the SDL CMake support
Now's the time!
One of the things I'm interested in is consolidation between the various CMake related files for the main library. Ideally I want to go to one file and make changes when I'm adding new functionality. If it makes more sense to split things out, I'd like to understand why.
Me too MinGW 64 is not compiling with no configure. No idea how to set up cmake for it. ATM mingw64 complete show stopper. If I get it compiling I will make a step by step instruction page.
For cross building with CMake, you need to let CMake know about 2 things: the toolchain + the target.
So the configuration command becomes:
cmake .. -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-g++ -DCMAKE_SYSTEM_NAME=Windows
This CMake page explains cross building with CMake more deeply: Cross Compiling With CMake
I think the "external interface" of SDL is quite okay (=configuration variables). The internals deserves a bit of refactoring, but this should not block anything. The minimum cmake version should be bumped anyways, as upstream cmake will drop support for version <3.6 in the upcoming cmake release. (There are ways to keep 3.0 support, but it won't make our lives easier.)
I have yet to get back to it. Will squeeze some time tomorrow/Wed, to see if I can get MinGW64 to function with the build.
On Tue, May 23, 2023 at 4:07 PM Anonymous Maarten @.***> wrote:
I think the "external interface" of SDL is quite okay (=configuration variables). The internals deserves a bit of refactoring, but this should not block anything. The minimum cmake version should be bumped anyways, as upstream cmake will drop support for version <3.6 in the upcoming cmake release. (There are ways to keep 3.0 support, but it won't make our lives easier.)
— Reply to this email directly, view it on GitHub https://github.com/libsdl-org/SDL/issues/6574#issuecomment-1560189007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYI5V5DAAV5KFNLBSKQKZALXHUYKBANCNFSM6AAAAAASHIFXBQ . You are receiving this because you commented.Message ID: @.***>
Is there a reason, the list of symbols that must be checked for availability by libc is different for Windows and other platforms?
Windows: https://github.com/libsdl-org/SDL/blob/4f58445f0389ca1a2a7d4bb03248007484038df1/CMakeLists.txt#L1101 other: https://github.com/libsdl-org/SDL/blob/4f58445f0389ca1a2a7d4bb03248007484038df1/CMakeLists.txt#L1167-L1171
The latter list does not test for modf and modff. Can't I just define this list once, and re-use it for all platforms?
The original reason was to avoid looking for symbols that are known not to exist, but at this point I think it makes sense to use a single list for consistency.
After I posted that image, I noticed MSVC skips detection.
I suppose it's safer to detect in both cases.
On MSVC, this code is not executed anyways by default because SDL_LIBC is OFF by default.
Do we actually need to test for Vulkan on unix? https://github.com/libsdl-org/SDL/blob/f082c68b2ff564a7c63edba3551fadfe3b02970a/CMakeLists.txt#L1543-L1547
Right now, the wayland/x11 code simply loads the Vulkan loader (libvulkan.so.1) with dlopen (same for Windows' vulkan-1.dll and Macos' libvulkan.dylib). No system headers are required, as SDL ships khronos headers.