Bug#951087: Bug#952105: planetblupi: FTBFS: blupi.h:23:10: fatal error: SDL.h: No such file or directory

[Simon McVittie]

On Sun, 23 Feb 2020 at 08:56:48 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > In file included from /<<PKGBUILDDIR>>/src/action.h:23,
> >                  from /<<PKGBUILDDIR>>/src/action.cxx:24:
> > /<<PKGBUILDDIR>>/src/blupi.h:23:10: fatal error: SDL.h: No such file or directory
> >    23 | #include <SDL.h>

Many games make wrong-but-usually-true assumptions about where the SDL2
headers and libraries can be found, but this one is particularly creative:
it assumes that SDL2 is installed in the same ${prefix} as planetblupi,
*and* that the SDL2 headers can be found in ${prefix}/include/SDL2.

Obviously, this is not how things are meant to work: it should be possible
to install SDL with --prefix=/opt/stuff and the games with
--prefix=$HOME/Games (or CMake equivalent) if that's what you want to do.

Despite not being considered correct, planetblupi's assumptions used to
work before we modified SDL2 to be multiarch co-installable
(<https://bugs.debian.org/909740>). There are two ways to address this
bug:

- Fix planetblupi to stop making this assumption
  (<https://salsa.debian.org/games-team/planetblupi/merge_requests/2>,
  or equivalently the attached patch);
- Change SDL2 so the assumption is true again
  (for example <https://salsa.debian.org/sdl-team/libsdl2/merge_requests/3>
  which also resolves <https://bugs.debian.org/951087>)

I've verified that either of these is sufficient to fix the FTBFS (compiled
successfully but not otherwise tested). For best robustness, I think we
would ideally do both.

    smcv