On Fri, 28 Sep 2018 at 08:30:27 +0300, Adrian Bunk wrote: > In file included from /usr/include/SDL2/SDL_main.h:25, > from /usr/include/SDL2/SDL.h:32, > from > /build/1st/fifechan-0.1.4+git20180904/include/fifechan/sdl/sdlgraphics.hpp:68, > from > /build/1st/fifechan-0.1.4+git20180904/include/fifechan/sdl.hpp:68, > from > /build/1st/fifechan-0.1.4+git20180904/src/sdl/sdl.cpp:69: > /usr/include/SDL2/SDL_stdinc.h:31:10: fatal error: SDL_config.h: No such file > or directory > #include "SDL_config.h" > ^~~~~~~~~~~~~~ > > Root cause: > > $ pkg-config --cflags sdl2 > -D_REENTRANT -I/usr/include/SDL2 > $ sdl2-config --cflags > -I/usr/include/SDL2 -D_REENTRANT > $ dpkg -S SDL_config.h > libsdl2-dev:amd64: /usr/include/x86_64-linux-gnu/SDL2/SDL_config.h
This is a regression caused by fixing #909740. Hugh McMaster correctly pointed out that /usr/include/<triplet> is one of the default search paths for headers. However, SDL_config.h is designed to be included as <SDL_config.h> after -I/usr/include/SDL2, not as <SDL2/SDL_config.h>, according to the design documented in <https://ometer.com/parallel.html> and popularized by packages like GLib and GTK+; so moving it to /usr/include/<triplet>/SDL2 does not make it includable. How was the patch in #909740 tested? If sdl2-config didn't exist, then this would be easy to fix by adding -I/usr/include/<triplet>/SDL2 to the pkg-config file (similar to what happens in GLib); but doing the same thing in sdl2-config would give it per-architecture variation and make it non-co-installable, so that isn't an option here. Here is a possible solution that I think respects all the constraints, although I have not tested it: * move SDL_config.h to /usr/include/<triplet>/SDL2/_real_SDL_config.h or similar (so that it has the same level of parallel-installability as SDL2 itself, and is clearly not part of the SDL API) * create /usr/include/SDL2/SDL_config.h containing: /* Debian-specific, for multiarch support */ #include <SDL2/_real_SDL_config.h> To avoid regressions like this in future, I would recommend adding an autopkgtest that compiles C code that calls some trivial function from SDL in the most recommended way, and checks that it works correctly, similar to debian/tests/build in packages like dbus and glib2.0. In the case of SDL2, it should probably be compiled twice: once using pkg-config to get the required CFLAGS and libraries, and once using sdl2-config, to make sure both work. smcv