Bug#951087: libsdl2-dev: Packages that embed FindSDL2.cmake fail to find SDL2

[Simon McVittie]

Control: reassign -1 libsdl2-dev 2.0.10+dfsg1-2
Control: retitle -1 libsdl2-dev: Packages that embed FindSDL2.cmake fail to find SDL2
Control: affects -1 + hedgewars openjk
Control: tags -1 + patch

On Tue, 11 Feb 2020 at 01:45:15 +0100, Andreas Beckmann wrote:
> openjk FTBFS against libsdl2 2.0.10+dfsg1-2 which has moved the headers
> to an arch-dependent location:
> 
> [ 53%] Building CXX object code/CMakeFiles/openjo_sp.x86_64.dir/client/cl_cgame.cpp.o
> cd "/build/openjk-0~20191030.4881be7~dfsg/obj/code" && /usr/bin/c++  -DARCH_STRING=\"x86_64\" -DFINAL_BUILD -DJK2_MODE -DSOURCE_DATE="\"Nov  2 2019\"" -D_JK2EXE -I"/build/openjk-0~20191030.4881be7~dfsg/shared" -I"
> /build/openjk-0~20191030.4881be7~dfsg/code" -I"/build/openjk-0~20191030.4881be7~dfsg/lib/gsl-lite/include" -I"/build/openjk-0~20191030.4881be7~dfsg/lib/minizip/include"  -g -O2 -fdebug-prefix-map=/build/openjk-0~2
> 0191030.4881be7~dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -Wno-strict-aliasing -Wno-unused-but-set-variable  
>  -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -msse2 -std=c++11 -Wall -Wno-invalid-offsetof -Wno-write-strings -Wno-comment -fsigned-char -mstackrealign -mfpmath=sse   -fvisibility=hidden -o CMakeFiles/openjo_sp.x86_6
> 4.dir/client/cl_cgame.cpp.o -c "/build/openjk-0~20191030.4881be7~dfsg/code/client/cl_cgame.cpp"
> In file included from /build/openjk-0~20191030.4881be7~dfsg/code/client/cl_cgame.cpp:34:
> /build/openjk-0~20191030.4881be7~dfsg/shared/sys/sys_loadlib.h:39:11: fatal error: SDL.h: No such file or directory
>    39 | # include <SDL.h>
>       |           ^~~~~~~

Reproducer attached. I think this is a regression in SDL2 with #909740.
hedgewars seems to FTBFS on the reproducible-builds infrastructure for the
same reason (no bug filed yet).

Since SDL 2.0.6, the recommended way to link to a system copy of SDL2
from a CMake project is to behave like debian/tests/cmake-example
in the current package - use find_package(SDL2) without a FindSDL2
macro. However, not all upstream projects that build using CMake have
caught up with this yet. The reproducer for this bug adds a
debian/tests/cmake-findsdl2 that represents this.

The specific implementation of FindSDL2 in the reproducer
was taken from openjk, but it's regularly copied around, and
can be found in hedgewars, spring and many other packages:
https://codesearch.debian.net/search?q=Other+versions+link+to+-lSDL2main&literal=1
I personally think the FindFoo modules are reminiscent of the worst parts
of Autotools (from which the Unix world was able to escape by inventing
pkg-config), but there's a significant amount of code that relies on
them, much of which is not well-maintained, so it seems desirable to
keep compatibility.

Inclusion of a vaguely similar file in CMake was rejected in
<https://github.com/Kitware/CMake/pull/149>.

The solution I originally proposed for #909740 back in 2018 (MR !3) does
not appear to suffer from this issue, but the alternatives I implemented
in 2019 in response to reluctance to apply !3 (MRs !4 and !5) do suffer
from it, and !5 is the implementation that was chosen for application in
the end.

I think the best solution for this is to
revert !5 and go back to !3. Please consider
<https://salsa.debian.org/sdl-team/libsdl2/merge_requests/3>.

Or if you have other ideas for fixing this, I'm open to suggestions.
I would recommend making sure that the new autopkgtest coverage passes.

    smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-d-tests-Assert-that-packages-that-embed-FindSDL2.cma.patch
Type: text/x-diff
Size: 14798 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-sdl-maintainers/attachments/20200211/43ebb7ec/attachment-0001.patch>