On Mon, 09 Dec 2019 at 19:08:05 +0100, Felix Geyer wrote: > On a second though I fear having the include files of libsdl2 and libsdl2-* > in different paths will break some build systems. > > A random example I quickly found: > https://sources.debian.org/src/neverball/1.6.0+git20180603-2/Makefile/
Good point. Build systems like this assume that sdl2-config is sufficient to find all the SDL2_foo family, not just the main library. > One option would be to add -I/usr/include/SDL2 to sdl2-config or pkg-config > but I'm not sure if that would cover all cases. If neverball was using `pkg-config --cflags SDL2_ttf` then that would just give it -I/usr/include/SDL2, so it seems like that ought to be sufficient. I suppose if one of the SDL2_foo family uses #include "SDL_bar.h" and expects to find an adjacent SDL2 that way, or if something tries to second-guess the compiler and read header files directly, that might be a reason to revert https://salsa.debian.org/sdl-team/libsdl2/merge_requests/5 (the one that goes via pkg-config) and apply https://salsa.debian.org/sdl-team/libsdl2/merge_requests/3 (my original proposal with a forwarding header) instead - that's the only solution I could see that keeps most SDL headers in the same place they have always been. (Alternatively, you could switch all the SDL2_foo packages to use the multiarch include directory "unnecessarily", just to make them consistent, but that's more avoidable uploads and header duplication.) smcv
