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

[Simon McVittie]

On Sun, 30 Sep 2018 at 14:04:56 +0000, Hugh McMaster wrote:
> I'm attaching a patch showing how the trick with $CC works. It needs 
> more testing.

Interesting. I think I still prefer the forwarding header, but either
could work.

For the short term, I'm preparing a NMU that reverts the multiarch change
and adds an autopkgtest that confirms that the package is usable, because
libsdl2-dev is currently unusable, and that's a considerably worse bug
than not being multiarch-friendly.

After that, I think it would make most sense for the SDL maintainer
team to choose one of the working approaches to multiarch, check that
it does in fact work, and use it to re-close the multiarch bug.

> > * (maybe) when compiling with `sdl2-config --cflags` or
> >  `pkg-config --cflags SDL2`, #include <sdl_config.h> must result in the
> >   config header being included (because apps/games might do this)
> 
> Well, it must be locatable. I don't see this as a problem, because 
> SDL_config.h was previously installed in /usr/include, so it would have
> been locatable then, even if it was not #included.

Sorry, I don't understand that. Please could you rephrase? I don't see how
C code would be expected to "locate" a header, except by #include'ing it?

SDL_config.h was not previously installed in /usr/include, it was
previously installed in /usr/include/SDL2; so it was only possible to
#include it if you had -I /usr/include/SDL2 in your compiler flags. This
is correct for parallel-installable packages like SDL2, which is meant
to be parallel-installable with SDL 1.2.

(Your email client seems to be systematically lower-casing anything that
appears in angle brackets, at least in quoted text, which is unhelpful
when discussing case-sensitive languages. Please consider using a
different client for technical discussion.)

> > I don't mean that /usr/include/SDL2/SDL_config.h would contain any
> > #defines at all; I mean that it would be literally one comment and one
> > #include (of a file that cpp will find in an architecture-dependent
> > location on its default include path, which can therefore have
> > architecture-dependent contents).
> 
> Right. My only concern with this solution is whether $CC will know to 
> use the correct architecture-dependent location. I'm not too familiar
> with how this works, so it could be fine.

Yes, Debian's compilers have /usr/include/<triplet> on their default
inclusion path. You'll see this in action if you inspect libffi-dev,
for example.