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
