Detect SDL2 headers using __has_include

[Falcury]

This adds a __has_include condition to the #include directives for the SDL2 header files in backends/imgui_impl_sdl.cpp, so that the SDL2 header files can be found in multiple places.

The reason is that the location of the SDL2 headers seems to vary and can be either at:

• <SDL2/SDL.h> / <SDL2/SDL_syswm.h> - this is the case on my Linux system and in my Windows set-up.
• <SDL.h> / <SDL_syswm.h> - this is the case on my macOS system (with SDL2 installed using MacPorts).

Checking first for the existence of the header files with the added SDL2/ prefix seemed the best option to me (as opposed to doing it the other way around), because without the prefix the headers from SDL-1.2 might accidentally get included instead of the SDL2 headers if there was also an old SDL 1 version installed on the system.

If __has_include is not supported by the compiler, there is a fallback to the original #include directives, without the SDL2/ prefix.

[PathogenDavid]

this is the case on my Linux system and in my Windows set-up.

Your setup is wrong. SDL expects you to reference its include directory directly, none of SDL's samples use a prefix.

[Falcury]

Your setup is wrong. SDL expects you to reference its include directory directly, none of SDL's samples use a prefix.

That may be so, and as far as I can tell from the official libsdl.org wiki the way you say is indeed the recommended approach.

However, tutorials found online in various places are in fact inconsistent about this. For example, you can find multiple tutorials on websites linked from the official libsdl.org wiki, where the <SDL2/SDL.h> setup is used. (This is the way I learned it, and so far my setup worked fine for me...)

Examples (found on websites linked from the libsdl.org wiki): http://www.sdltutorials.com/sdl-2.0-basics-and-textures https://www.willusher.io/sdl2%20tutorials/2013/08/15/lesson-0-mingw

Another example (found elsewhere): https://gigi.nullneuron.net/gigilabs/how-to-set-up-sdl2-on-linux/

So, I would argue that there is no one 'correct' approach. Both styles are covered by the change I proposed.

[ebachard]

If I'm not wrong, on Linux, the normal way to find SDL (1.x) and SDL2 (2.0.y) is to use sdl-config [respectively] sdl2-config at configure time. Source : https://wiki.libsdl.org/Installation

e.g.:

SDL:

me@my-machine:~$ sdl-config --flags --version
Usage: sdl-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]
eme@my-machine:~$ sdl-config --version
1.2.15

me@my-machine:~$ sdl-config --cflags
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT

me@my-machine:~$ sdl-config --libs
-L/usr/lib/x86_64-linux-gnu -lSDL

SDL2:

me@my-machine::~$ sdl2-config --help
Usage: /usr/bin/sdl2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]

me@my-machine:~$ sdl2-config --cflags
-I/usr/include/SDL2 -D_REENTRANT

Looks like its the same thing on Windows:

me@my-machine:~/Devel/CROSS_COMPILATION/SDL2/SDL2-2.0.9/build-win64$ ./sdl2-config
Usage: ./sdl2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]

me@my-machine:~/Devel/CROSS_COMPILATION/SDL2/SDL2-2.0.9/build-win64$ ./sdl2-config --cflags
-I/usr/local/cross-tools//x86_64-w64-mingw32/include/SDL2 -Dmain=SDL_main

Does it work on Mac OS X too ?

[ocornut]

The problem with this approach is that if there are other compilation units using a regular #include and both SDL2/SDL.h and SDL.h are accessible in include paths, it creates a situation were people accidentally use two versions of SDL in different compilation units, leading to general havoc/confusion.

At minima this should be done to all occurrences of SDL.h includes (9 matches in our repository), and without the extra indents.

[rokups]

sdl(2)-config produces include path with ../SDL(2) on all platforms (including macports too). Seems to me this is a convention to be followed. Preferring SDL2/SDL.h over SDL.h would definitely break projects that ship their own version of SDL and are compiled on linux machines with SDL installed. In such case a project following conventions would have ../third_party/SDl2/include/SDL2 in include path so SDL.h can be found, but system also always has /usr/include in include paths and here we can find /usr/include/SDL2/SDL.h. So project would link to a bundled SDL2 while using headers from a system version.