On Tue, 10 Dec 2019 at 21:56:51 +1100, Hugh McMaster wrote:
> As a test, I built and installed SDL2 with Simon's patch, then built
> and installed SDL2-ttf. That worked fine out of the box.
>
> Neverball failed to build because it couldn't find
> /usr/include/SDL2/SDL_ttf.h, which is, of course, not part of the
> default search path.
With which of my patches? I sent three merge requests (!3, !4, !5) with
different ways to solve multiarch coinstallability, each with different
advantages and disadvantages, in the hope that at least one of them would
be considered acceptable and unblock progress on this bug.
I would expect that !5 (the one that Felix has now merged, using
$PKG_CONFIG) and !4 (closer to what you and Adrian suggested, using $CC)
would break the neverball use-case when used as-is, as Felix pointed out.
This is because they do not have -I/usr/include/SDL2 in
`sdl2-config --cflags`, so #include <SDL_ttf.h> won't work. To avoid that
regression, if !5 (or !4) is still the preferred option, one option is
to hard-code -I/usr/include/SDL2 in addition to -I${libdir}/SDL2.
However, I would have expected !3 (which would now mean reverting the
main commit from !5 and applying !3 instead) to work OK for neverball's
use-case, because it leaves -I/usr/include/SDL2 in `sdl2-config --cflags`,
the same as in the non-multiarch-capable implementation currently in
the archive; so I'd be surprised if this breaks neverball. If this is
the one you tested, please could you indicate the exact patch or git
commit you used?
When I get a chance to work on this again, I'll add an autopkgtest that
does what neverball relies on, and re-test with that.
I still like !3 best, but I'm happy to fix !5 (or even !4) to avoid the
neverball regression if the SDL2 maintainers would prefer that.
> Wouldn't it be easier to just patch sdl2.pc to add
> ${prefix}/include/SDL2 to CFLAGS, as Felix suggested? That should
> catch all #includes.
That would be one way to modify !5 so that neverball works, yes.
> Also, this small addition has far less overhead than multiple copies
> of the SDL2 headers.
I'm not sure I understand what you're proposing or opposing here. If
you have two architectures' versions of libsdl2-dev installed, !4 and
!5 both duplicate the headers from the main SDL2 library; !3 does not.
I don't think anyone has proposed a solution that would involve
duplicating the SDL2 headers within one architecture.
Rebuilding SDL2_ttf, SDL2_mixer etc. with
--includedir=/usr/include/${multiarch} would duplicate those libraries'
headers between architectures, although those libraries' headers are a
lot smaller than the main SDL2 library's headers anyway, so the impact
of doing so is small when compared with choosing !4 or !5 over !3.
However, I agree that this is not a great solution, because it would
require more coordination between packages than just changing libsdl2.
smcv
