Bug#909740: libsdl2-dev: No longer multi-arch co-installable

[Simon McVittie]

In an attempt to unblock this bug I've implemented several versions of a
solution to it, so that the SDL2 maintainers can choose their favourite
and merge it.

On Sun, 30 Sep 2018 at 22:17:05 +0100, Simon McVittie wrote:
> Ugh, I'd missed that there's a third API for building dependent software
> (the CMake files). The autopkgtest that I added should ideally test this
> one too, but I think that'll probably need a proper CMake build system
> (at least one CMakeLists.txt), not just a one-liner?

New autopkgtest proposed in
<https://salsa.debian.org/sdl-team/libsdl2/merge_requests/2>. It passes
for the current state of libsdl2-dev, and for all my implementations.

On Sun, 30 Sep 2018 at 19:08:26 +0100, Simon McVittie wrote:
> https://salsa.debian.org/smcv/libsdl2/commits/multiarch-forwarding-header
> 
> I prefer this approach because it's relatively self-contained, and
> doesn't require us to carry non-upstreamable patches to upstream code
> or rely on a relatively obscure Debian-specific compiler option.

Now at <https://salsa.debian.org/sdl-team/libsdl2/merge_requests/3>.
I think this is still my preferred option, but the others are also viable.

On Sun, 30 Sep 2018 at 22:02:59 +0300, Adrian Bunk wrote:
> Wouldn't the least invasive option be a combination of
> 1. my --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) suggestion plus
> 2. the sdl2-config patching from Hugh

I've implemented this alternative at
<https://salsa.debian.org/sdl-team/libsdl2/merge_requests/4>.

I've also implemented a version of this suggestion,
but using $PKG_CONFIG instead of $CC in sdl2-config:
<https://salsa.debian.org/sdl-team/libsdl2/merge_requests/5>. I think
this is maybe a bit nicer than !4?

Other interested developers are of course welcome to propose something
better - I'm sure there are other possibilities that I've missed.

Do the SDL2 maintainers have any comments on these MRs, or preference
between them?

Thanks,
    smcv