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
