This provides a linking interface that matches the one available when `find_package()` is used, by aliasing all of SDL's public targets into the SDL2:: namespace. Thus, dependees link to the same-named targets regardless of how SDL was acquired.
This approach permits the use of wrappers around CMake's FetchContent API such as https://github.com/cpm-cmake/CPM.cmake
Aaron Barany
The CMake build for SDL doesn't set SDLMAIN_SOURCES on iOS to the sources in src/main/ios. As a result, SDL fails to initialize since it falls back to the dummy main. Adding the line file(GLOB SDLMAIN_SOURCES ${SDL2_SOURCE_DIR}/src/main/uikit/*.c) fixes the issue.
Cameron Cawley
stdlib: Added SDL_round, SDL_roundf, SDL_lround and SDL_lroundf
The default implementation is based on the one used in the Windows RT video driver.
Sebastian Vargas Vargas
Running CMake configure from a Windows Subsystem for Linux using Visual Studio Code Remote doesn't generate the header file with the current source revision, it throws "/home/sebva/SDL/build-scripts/updaterev.sh: 13: cannot create /mnt/c/Users/sebva/.vscode/extensions/ms-vscode-remote.remote-wsl-0.44.4/include/SDL_revision.h.new: Directory nonexistent".
Tom Seddon
2nd time lucky, perhaps. patch 2 applies to current HEAD at time of writing - 4eb049c9bb1ca94efe3c40b57beda3169984d0cb from https://github.com/SDL-mirror/SDL.
This basically goes back to what was there originally, but now manually adding "-x objective-c" to the clang command line rather than "-ObjC". clang is then invoked without the "-x c" that was causing the problem, the snippet builds, and Metal is detected. (I had a quick trawl through the cmake code, but I couldn't see where this is handled.)
I was moved to try this after finding SDL's own CHECK_OBJC_SOURCE_COMPILES macro, and noting what it does: 4eb049c9bb/cmake/macros.cmake (L67)
An alternative fix of course would be to use CHECK_OBJC_SOURCE_COMPILES instead of cmake's check_objc_source_compiles - but that had the same problem of getting confused by "return 0;". (Maybe that's because it's a macro? I'll defer to a cmake expert on this one.)
I decided in the end to err on the side of leaving things looking basically the same as they were before my first patch.
Tom Seddon
This is as of commit 50d804ea729accf9e3a9ce83238d0a2976a17545 from https://github.com/SDL-mirror/SDL, which is HEAD as I write (apologies, not confident with Mercurial)
# Config
macOS: 10.14.6 (18G6042)
cmake --version: cmake version 3.16.20200101-g23e782c
clang --version: Apple clang version 11.0.0 (clang-1100.0.33.17)
Xcode version: Version 11.3.1 (11C504)
# Repro steps
Run the following commands in the shell.
cd /tmp/
git clone https://github.com/SDL-mirror/SDL
mkdir build.SDL
cd build.SDL
cmake -G ../SDL/
Examine cmake output.
# Expected result
Metal is detected.
# Actual result
It appears that Metal is not detected! Note this line in the summary:
-- RENDER_METAL (Wanted: 0): OFF
# Fix
Change check_c_source_compiles to check_objc_source_compiles. The cmake script tries to add -ObjC to the clang command line, but, for whatever reason, this doesn't seem to work.
Change the test source to have an empty main. The "return 0;" line seems to confuse cmake somehow, causing it to crap out with an error about HAVE_FRAMEWORK_METAL being an unknown argument. (Maybe I'm just dense, but it's not obvious to me what the problem is here.)
With these two changes:
-- RENDER_METAL (Wanted: ON): ON
Patch attached.
This works on capability bitfields that can either come from udev or
from ioctls, so it is equally applicable to both udev and non-udev
input device detection.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ivan Epifanov
Ozkan Sezer
Frank Praznik
Joshua Saxby
Christian Rauch
Sam Lantinga
Joel Linn
Manuel Alfayate Corchete
Simon McVittie