when using alternate unwind implementations like LLVM libunwind
this library is not provided yet the libunwind features are fully
implemented in main libunwind, making this hard dependency assumes
a particular libunwind implementation, this patch makes it optional
which makes the builds to work with llvm libunwind
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This makes it so that the generated targets are not interdependent,
which allows Linux distributions to split libraries into the
appropriate subpackages as needed.
Martin Gerhardy wrote:
If there is a variable named test, then cmake does variable-value comparison:
if (test STREQUAL "")
is equivalent to:
if ("${test}" STREQUAL "")
If there is no variable named test, then cmake does string literal comparison:
if (test STREQUAL "")
is equivalent to:
if ("test" STREQUAL "")
That means basically - the current stuff works - but is not how it should be done.
Fixes https://github.com/libsdl-org/SDL/issues/2100
- SDL_CLOCK_GETTIME now defaults to ON to match autotools build
- Add detection of float.h and Xdbe
- Fix detection of pthread_setname_np() (requires _GNU_SOURCE)
- Move SDL_USE_IME definition into SDL_config.h.cmake
This means it now works with any CMake released since 2014 instead of 2018.
This was mostly just readding some special cases, and requiring 3.11.0 only
for Windows Stores apps, which isn't unreasonable. The biggest concern is
a Linux distribution not having a recent CMake; most other places will be
manually downloading and installing their own CMake.
Fixes#4930.
This API and implementation comes from the Unreal Engine branch of SDL, which
originally called this "SDL_ConfineCursor".
Some minor cleanup and changes for consistency with the rest of SDL_video, but
there are two major changes:
1. The coordinate system has been changed so that `rect` is _window_ relative
and not _screen_ relative, making it easier to implement without having
global access to the display.
2. The UE version unset all rects when passing `NULL` as a parameter for
`window`, this has been removed as it was an unused feature anyhow.
Currently this is only implemented for X, but can be supported on Wayland and
Windows at minimum too.
SDL_config.h *can* define SDL_JOYSTICK_WGI. On builds with the Windows
10 SDK available, this allow implementing trigger rumbling on Xbox One
controllers. The files included in the Visual Studio Solution in
VisualC\SDL.sln *do* have this define set.
fix#4859
This cmake is 3 years old, but it removes confusion about the CFLAGS
environment variable (as of CMake 3.10.0, reference PR #4681) and also
consolidates resolves the need to have a separate requirement for Windows
Store apps (which requires CMake 3.11.0).
CMake has standard means of setting compiler flags, such as the
-DCMAKE_C_FLAGS command line for general-purpose flags, and
-DCMAKE_BUILD_TYPE for letting it choose reasonable release/debug/etc
defaults. Trying to emulate the configure script is incorrect and confusing
here.
Fixes#1819.
Vista and later provide the SleepConditionVariableCS() function for this.
Since SDL_syscond_srw.c doesn't require SRW locks anymore, rename it to
SDL_syscond_cv.c which better reflects the implementation of condition
variables rather than the implementation of mutexes.
Fixes#4051.
Although GCC and Clang automatically generate color diagnostics on
terminal output, they do not do so when the compiler output is piped
through another process, like in the case for ninja-build and ccache.
Similarly, it would also be nice to be able to see the color diagnostics
on the CI build log in the web interface provided by the CI providers.
- cmake, configure (CheckDLOPEN): --enable-sdl-dlopen is now history..
detach the dl api discovery from SDL_LOADSO_DLOPEN functionality.
define HAVE_DLOPEN. also define DYNAPI_NEEDS_DLOPEN (CheckDLOPEN is
called only for relevant platforms.)
- update SDL_config.in and SDL_config.cmake accordingly.
- SDL_dynapi.h: set SDL_DYNAMIC_API to 0 if DYNAPI_NEEDS_DLOPEN is
defined, but HAVE_DLOPEN is not.
- pthread/SDL_systhread.c: conditionalize dl api use to HAVE_DLOPEN
- SDL_x11opengl.c, SDL_DirectFB_opengl.c, SDL_naclopengles.c: rely
on HAVE_DLOPEN, not SDL_LOADSO_DLOPEN.
- SDL_config_android.h, SDL_config_iphoneos.h, SDL_config_macosx.h,
SDL_config_pandora.h, and SDL_config_wiz.h: define HAVE_DLOPEN.
Closes: https://github.com/libsdl-org/SDL/pull/4351
According to https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html
`${CMAKE_INSTALL_LIBDIR} ` is only variable which should be used as base
directory. Without that patch on 64 bit archs libraries, cmake modules and
pkgconfig file are installed for example in /usr/lib6464 base directory.
This patch fixes#4621.
Signed-off-by: Tomasz Kłoczko <koczek@github.com>
These came from HaikuPorts, specifically this patchset:
462947dd4f/media-libs/libsdl2/patches/libsdl2-2.0.14.patchset
This is just the part that is _not_ Haiku-specific. I wanted this in a
separate commit though, since I'm not really a CMake expert; if this causes
problems and we need to bisect to it, we won't be confused about it being a
Haiku issue when we get here.
Fixes#4092.
(and probably others.)
These came from HaikuPorts, specifically this patchset:
462947dd4f/media-libs/libsdl2/patches/libsdl2-2.0.14.patchset
This is just the Haiku-specific bits; the more general parts about install
dirs will be split into a different commit here.
Reference issue #4092.
When building SDL2 from git with CMake, you got libSDL2-2.0.so.1
instead of .0 (as it's the case when building with autotools).
This was caused by using LT_REVISION instead of LT_MAJOR for SOVERSION.
fixes#4310
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>
- SDL_config.h.in: add missing defines SDL_SENSOR_COREMOTION
and SDL_SENSOR_WINDOWS (configure did set SDL_SENSOR_WINDOWS
but it never went in SDL_config.h or Makefile.)
- SDL_config.h.cmake: remove duplicated SDL_SENSOR_XXX cmake
defines.
- autofoo, cmake: check for sensorsapi.h header before enabling
windows sensors.
Apparently the "-x objective-c" made it down to the linker, who then treats
the .o file as Objective-C source code. Apparently the -ObjC argument does
the same thing but gets ignored by the linker.
Fixes Bugzilla #4988.
Giovanni Bajo
The CMake build system supports several audio frameworks for Linux: one of them is sndio.
All frameworks can be built with "runtime linking" (that is, using dlopen to load the library at runtime). In sdlchecks.cmake, there's code to do the same with sndio:
=================================================================
# Requires:
# - n/a
# Optional:
# - SNDIO_SHARED opt
# - HAVE_DLOPEN opt
macro(CheckSNDIO)
if(SNDIO)
# TODO: set include paths properly, so the sndio headers are found
check_include_file(sndio.h HAVE_SNDIO_H)
find_library(D_SNDIO_LIB sndio)
if(HAVE_SNDIO_H AND D_SNDIO_LIB)
set(HAVE_SNDIO TRUE)
file(GLOB SNDIO_SOURCES ${SDL2_SOURCE_DIR}/src/audio/sndio/*.c)
set(SOURCE_FILES ${SOURCE_FILES} ${SNDIO_SOURCES})
set(SDL_AUDIO_DRIVER_SNDIO 1)
if(SNDIO_SHARED)
if(NOT HAVE_DLOPEN)
message_warn("You must have SDL_LoadObject() support for dynamic sndio loading")
else()
FindLibraryAndSONAME("sndio")
set(SDL_AUDIO_DRIVER_SNDIO_DYNAMIC "\"${SNDIO_LIB_SONAME}\"")
set(HAVE_SNDIO_SHARED TRUE)
endif()
else()
list(APPEND EXTRA_LIBS ${D_SNDIO_LIB})
endif()
set(HAVE_SDL_AUDIO TRUE)
endif()
endif()
endmacro()
=================================================================
The feature is gated by an option called SNDIO_SHARED. It is also fully implemented in SDL_sndioaudio.c
Unfortunately, it seems there is a missing line in CMakeLists.txt, so SNDIO_SHARED is not defined:
======================================================================
set_option(ALSA "Support the ALSA audio API" ${UNIX_SYS})
dep_option(ALSA_SHARED "Dynamically load ALSA audio support" ON "ALSA" OFF)
set_option(JACK "Support the JACK audio API" ${UNIX_SYS})
dep_option(JACK_SHARED "Dynamically load JACK audio support" ON "JACK" OFF)
set_option(ESD "Support the Enlightened Sound Daemon" ${UNIX_SYS})
dep_option(ESD_SHARED "Dynamically load ESD audio support" ON "ESD" OFF)
set_option(PULSEAUDIO "Use PulseAudio" ${UNIX_SYS})
dep_option(PULSEAUDIO_SHARED "Dynamically load PulseAudio support" ON "PULSEAUDIO" OFF)
set_option(ARTS "Support the Analog Real Time Synthesizer" ${UNIX_SYS})
dep_option(ARTS_SHARED "Dynamically load aRts audio support" ON "ARTS" OFF)
set_option(NAS "Support the NAS audio API" ${UNIX_SYS})
set_option(NAS_SHARED "Dynamically load NAS audio API" ${UNIX_SYS})
set_option(SNDIO "Support the sndio audio API" ${UNIX_SYS})
set_option(FUSIONSOUND "Use FusionSound audio driver" OFF)
dep_option(FUSIONSOUND_SHARED "Dynamically load fusionsound audio support" ON "FUSIONSOUND" OFF)
======================================================================
You can see that all frameworks define a "dep_option" NAME_SHARED, and SNDIO is the only one where the option is missing.
This means that runtime loading of sndio is never activated. If sndio is found at configuration time, it is always activated in "linked" mode, so that the final binary will have a load-time dependency with libsdnio. This is unfortunate.
To fix the problem, it is sufficient to add this line:
dep_option(SNDIO_SHARED "Dynamically load the sndio audio API" ${UNIX_SYS} ON "SNDIO" OFF)
I've verified that this fixes the bug, and sndio can now be dynamically loaded as expected.
wengxt
Due to the new major fcitx version is coming close, the existing code need to be ported to use new Fcitx dbus interface.
The new dbus interface is supported by both fcitx 4 and 5, and has a good side effect, which is that it will work with flatpak for free. Also the patch remove the dependency on fcitx header. Instead, it just hardcodes a few enum value in the code so need to handle the different header for fcitx4 or 5.
A project being built entirely statically will call pkg-config with
--static, which utilises the Libs.private field. Conversely it will
not use --static when not being built entirely statically, even if
there is only a static build of SDL available. This will most likely
cause the build to fail due to underlinking unless we merge the Libs
fields.
This is what the Meson build system does when it generates pkg-config
files. This also also follows the behaviour of sdl2-config.
At the same time, the runtime linker flags are not applicable to
static-only builds so only add them for shared builds.
David Ludwig
I have created a new driver for SDL's Joystick and Game-Controller subsystem: a Virtual driver. This driver allows one to create a software-based joystick, which to SDL applications will look and react like a real joystick, but whose state can be set programmatically. A primary use case for this is to help enable developers to add touch-screen joysticks to their apps.
The driver comes with a set of new, public APIs, with functions to attach and detach joysticks, set virtual-joystick state, and to determine if a joystick is a virtual-one.
Use of virtual joysticks goes as such:
1. Attach one or more virtual joysticks by calling SDL_JoystickAttachVirtual. If successful, this returns the virtual-device's joystick-index.
2. Open the virtual joysticks (using indicies returned by SDL_JoystickAttachVirtual).
3. Call any of the SDL_JoystickSetVirtual* functions when joystick-state changes. Please note that virtual-joystick state will only get applied on the next call to SDL_JoystickUpdate, or when pumping or polling for SDL events (via SDL_PumpEvents or SDL_PollEvent).
Here is a listing of the new, public APIs, at present and subject to change:
------------------------------------------------------------
/**
* Attaches a new virtual joystick.
* Returns the joystick's device index, or -1 if an error occurred.
*/
extern DECLSPEC int SDLCALL SDL_JoystickAttachVirtual(SDL_JoystickType type, int naxes, int nballs, int nbuttons, int nhats);
/**
* Detaches a virtual joystick
* Returns 0 on success, or -1 if an error occurred.
*/
extern DECLSPEC int SDLCALL SDL_JoystickDetachVirtual(int device_index);
/**
* Indicates whether or not a virtual-joystick is at a given device index.
*/
extern DECLSPEC SDL_bool SDLCALL SDL_JoystickIsVirtual(int device_index);
/**
* Set values on an opened, virtual-joystick's controls.
* Returns 0 on success, -1 on error.
*/
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualAxis(SDL_Joystick * joystick, int axis, Sint16 value);
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualBall(SDL_Joystick * joystick, int ball, Sint16 xrel, Sint16 yrel);
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualButton(SDL_Joystick * joystick, int button, Uint8 value);
extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualHat(SDL_Joystick * joystick, int hat, Uint8 value);
------------------------------------------------------------
Miscellaneous notes on the initial patch, which are also subject to change:
1. no test code is present in SDL, yet. This should, perhaps, change. Initial development was done with an ImGui-based app, which potentially is too thick for use in SDL-official. If tests are to be added, what kind of tests? Automated? Graphical?
2. virtual game controllers can be created by calling SDL_JoystickAttachVirtual with a joystick-type of SDL_JOYSTICK_TYPE_GAME_CONTROLLER, with naxes (num axes) set to SDL_CONTROLLER_AXIS_MAX, and with nbuttons (num buttons) set to SDL_CONTROLLER_BUTTON_MAX. When updating their state, values of type SDL_GameControllerAxis or SDL_GameControllerButton can be casted to an int and used for the control-index (in calls to SDL_JoystickSetVirtual* functions).
3. virtual joysticks' guids are mostly all-zeros with the exception of the last two bytes, the first of which is a 'v', to indicate that the guid is a virtual one, and the second of which is a SDL_JoystickType that has been converted into a Uint8.
4. virtual joysticks are ONLY turned into virtual game-controllers if and when their joystick-type is set to SDL_JOYSTICK_TYPE_GAMECONTROLLER. This is controlled by having SDL's default list of game-controllers have a single entry for a virtual game controller (of guid, "00000000000000000000000000007601", which is subject to the guid-encoding described above).
5. regarding having to call SDL_JoystickUpdate, either directly or indirectly via SDL_PumpEvents or SDL_PollEvents, before new virtual-joystick state becomes active (as specified via SDL_JoystickSetVirtual* function-calls), this was done to match behavior found in SDL's other joystick drivers, almost all of which will only update SDL-state during SDL_JoystickUpdate.
6. the initial patch is based off of SDL 2.0.12
7. the virtual joystick subsystem is disabled by default. It should be possible to enable it by building with SDL_JOYSTICK_VIRTUAL=1
Questions, comments, suggestions, or bug reports very welcome!
Mohamed
It would be useful to be able to do either `#include "SDL2/SDL.h"` or `#include "SDL.h"`. This patch allows that and adds compatibility with other build systems. It also allows differentiating between SDL1 and SDL2.
The Offscreen video driver is intended to be used for headless rendering
as well as allows for multiple GPUs to be used for headless rendering
Currently only supports EGL (OpenGL / ES) or Framebuffers
Adds a hint to specifiy which EGL device to use: SDL_HINT_EGL_DEVICE
Adds testoffscreen.c which can be used to test the backend out
Disabled by default for now
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=tvOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: appletvos, appletvsimulator, appletvos12.4, /full/path/to/AppleTVOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;x86_64")
When using a recent version of CMake (3.14+), this should make it possible to:
- build SDL for iOS, both static and dynamic
- build SDL test apps (as iOS .app bundles)
- generate a working SDL_config.h for iOS (using SDL_config.h.cmake as a basis)
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=iOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: iphoneos, iphonesimulator, iphoneos12.4, /full/path/to/iPhoneOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;armv7s")
Examples:
- for Simulator, using the latest, installed SDK:
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
- for Device, using the latest, installed SDK, 64-bit only
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64
- for Device, using the latest, installed SDK, mixed 32/64 bit
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"
- for Device, using a specific SDK revision (iOS 12.4, in this example):
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64
- for Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
cmake path/to/SDL -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
Callum McGing
While the CMake build checks for ibus and does enable the ibus backend with set(HAVE_IBUS_IBUS_H TRUE), this does not define SDL_USE_IME, thus CMake built SDL2 (as in Arch Linux) cannot use IME at all.
The attached patch fixes this behaviour when building against ibus. IME support will still fail when only fcitx is available on the build system.
This is currently supported on Linux and macOS. iOS and Android are not
supported at all, Windows support could be added with some changes to the libusb
backend. The Visual Studio and Xcode projects do not use this feature.
Based on Valve Software's hid.cpp, written in collaboration with Andrew Eikum.
Braden Obrzut
https://hg.libsdl.org/SDL/file/7dc39b047055/CMakeLists.txt#l911
I believe the following should also be specified there:
set(SDL_VIDEO_OPENGL_ES 1)
set(SDL_VIDEO_RENDER_OGL_ES 1)
As it is now GLES1 support is missing when building for Android despite it linking to the library.
Ozkan Sezer
A horde of strict aliasing violation warnings are emitted from joystick
layer, and also from a few other places. This happens with gcc-4.4.7 on
Linux CentOS 6.10. Some other sysjoystick would possibly have the same
warnings.
Attached my full log here. Example entry:
src/joystick/SDL_joystick.c: In function 'SDL_GetJoystickGUIDInfo':
src/joystick/SDL_joystick.c:1094: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules
tschwinger
Respect the BUILD_SHARED_LIBS variable when defined, and build either shared or static libs, which is CMake's default behavior (See https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html).
If the variable is not defined, the current behavior remains unchanged and both variants are built where the platform supports it. This way, it remains possible to build both in one shot, which seems convenient for distro builds and useful to promote some consistency between them.
tschwinger
Followup to #3651
As already noted by Ryan, no framework is being built, so we better install to lib/cmake.
That code was originally part of a patch submitted by David Demelier, whose credit BTW got lost (I combined his patch for #3572 with fixes for #2576 and #3613 resulting in #3651 because things started to depend on another).
I tested that the configuration files are found correctly in the new location on MacOS X based on a hint to the root (see https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure).
Manuel Sabogal
I noticed that the current Android.mk builds a libhidapi.so library for Android but the CMake build hasn't been updated to do so. I'll attach a patch that fixes this issue.
This lets you build a custom embedded device that roughly offers the "this
process is going to the background NOW" semantics of SDL on a mobile device.
From Tom Black:
I'm having problems initializing the sensor module. I'm compiling with a standard ./configure && make && sudo make install, and the module says it's enabled, but SDL_Init(SDL_INIT_EVERYTHING) is failing with SDL_GetError() returning "SDL not built with sensor support".
Author: Micha? Janiszewski <janisozaur+signed@gmail.com>
Date: Fri Sep 28 20:38:04 2018 +0200
CMake: fix building tests on Linux
In case where libunwind.h has been found, it will be used by compiler,
but linker wasn't updated to reflect use of this new library.
add HAVE_ENDPOINTVOLUME_H, HAVE_MMDEVICEAPI_H and HAVE_AUDIOCLIENT_H
in SDL_config.h.in, SDL_config.h.cmake, SDL_config_windows.h, and in
SDL_config_winrt.h.
Wayde Reitsma
After attempting to use SDL2 in the way described in this bug, I found the main issue was the includes not being added to the compiler command.
I found the issue was that the target_include_directories commands for the SDL2, SDL2-static and SDL2main targets only sets the public includes for installations using the INSTALL_INTERFACE generator expression.
I have written a patch to CMakeLists.txt that fixes this issue by adding another item to the target_include_directories commands, utilizing the BUILD_INTERFACE generator expression to correctly add the include directory during builds.
Previously the include path was {INSTALL_PREFIX}/include,
it is now {INSTALL_PREFIX}/include/SDL2 to be consistent with
the other build and package configuration systems.
Fixes#4128.
