Dear Maintainer,

I've upgraded an old system and now one program does not build any more.
When trying to configure it via cmake:

  CMake Error at /lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake:13 (message):
    File or directory //include/SDL2 referenced by variable SDL2_INCLUDE_DIR
    does not exist !
  Call Stack (most recent call first):
    /lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake:29 (set_and_check)
    CMakeLists.txt:331 (find_package)

One can see "usr" is missing in the file path, since there is no /include.
On the old system the usr migration hasn't happened yet, so it worked fine,
but now cmake starts looking for its files and first considers /lib, only then
/usr/lib.

sdl2-config.cmake does a relative path lookup, so that becomes a problem:

  get_filename_component(prefix "${CMAKE_CURRENT_LIST_DIR}/../../../.." ABSOLUTE)

4 dirs up of /lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake is /, while it
was /usr before ... Changing the cmake lookup to explicitly resolve symlinks
does not help, since only the dirs are linked, not the file it's considering.

I'm inclined to think this should be fixed in Debian, not cmake. The hackiest
solution is to just replace the line with

  set(prefix "/usr")

A bit safer would be to just do it if the previous call resolved to /, but I
don't know what all layouts are supported. If someone installed via chroot,
both ways would be broken. So a better solution would be something like:
copy CMAKE_CURRENT_LIST_DIR to a new var, replace /lib with /usr/lib in it,
use the new var for the prefix lookup instead.

This report is against 2.26.3, but I didn't see anything relevant in the changelog
for .5, hence the report.

Control: tags -1 + moreinfo
detects SDL's prefix as /usr, then ends up with SDL2_INCLUDE_DIR set to
/usr/include/SDL2 as expected.

If you download and unpack the libsdl2 source package, you'll find several
simple test projects in debian/tests/cmake-*/ which are all run by the
test script debian/tests/cmake - it's intended to be run via autopkgtest,
but you can just run it as ./debian/tests/cmake from an unpacked libsdl2
source package. Do those tests pass or fail on your system?

If those tests pass, perhaps you could modify one of them into a
simplified version of whatever project is failing for you?

Or if you are invoking cmake with special options, please try to edit
./debian/tests/cmake so that it uses similar options and reproduces
this error.

It seems you are not actually running Debian, so please report this to
Ubuntu if you haven't already. Debian contributors cannot generally
provide support for the packages in Ubuntu, many of which have been
modified (even if libsdl2 itself is the same in Debian and Ubuntu,
other relevant packages like cmake and the compiler might not be).

    smcv

Hello,

I was able to reproduce this bug on a debian bookworm installed recently.
I have the same issue, cmake, libsdl2-dev and the other dependencies were
installed through apt, not compiled from source, and CMAKE_CURRENT_LIST_DIR
is set to /lib/x86_64-linux-gnu/cmake/SDL2 so the cmake of the projects
fails.

How were you able to reproduce this? Please explain in more detail.

If you download and unpack the libsdl2 source package, you'll find several
simple test projects in debian/tests/cmake-*/ which are all run by the
test script debian/tests/cmake - it's intended to be run via autopkgtest,
but you can just run it as ./debian/tests/cmake from an unpacked libsdl2
source package. Do those tests pass or fail on your system?

If those tests pass, perhaps you could modify one of them into a
simplified version of whatever project is failing for you?

Or if you are invoking cmake with special options, please try to edit
./debian/tests/cmake so that it uses similar options and reproduces
this error.

    smcv