Bug#909778: libsdl2-dev: SDL_config.h no longer in cflags provided by pkg-config/sdl2-config

[Hugh McMaster]

On Friday, 28 September 2018 5:09 PM, Simon McVittie wrote:
> 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.

The best solution is to drop sdl2-config... but, sadly, that is in an ideal
world. Patching pkg-config is definitely the way to go.

A workaround for sdl2-config is to determine the multi-arch triplet
when calling the script:

    CC=${CC-cc}
    triplet=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//' )`

This is compatible with gcc and clang and voids the multi-arch file conflict
problem raised by Simon.

> 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="">

This is a interesting idea, but sounds messy due to the long list of 
#defines I expect it may need. Still, I'd like to see this to learn more.

> 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.

A good idea, yes.