We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4116 - Debian package provides bad sdl2-config.cmake
Summary: Debian package provides bad sdl2-config.cmake
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: build (show other bugs)
Version: HG 2.1
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-25 15:17 UTC by Raphnalor
Modified: 2020-04-20 07:03 UTC (History)
5 users (show)

See Also:

Attachments
good and bad SDL2Config files (8.41 KB, application/x-zip-compressed)
2018-03-25 15:17 UTC, Raphnalor 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Raphnalor 2018-03-25 15:17:02 UTC 
Created attachment 3215 [details]
good and bad SDL2Config files

When I build SDL2 from source with cmake using the following command

mkdir build
cd build
cmake ..
cmake --build . --target install

it makes file "SDL2Config.cmake" and others (see folder "good..." in the attachment) which are perfect config files for CMake containing imported targets "SDL2::SDL2" and "SDL2::SDL2main" which makes SDL2 comfortable to use in any CMake-based project.

However when I install SDL with command "apt-get install libsdl2-dev" it provides file "sdl2-config.cmake" (see folder "bad..." in the attachment) which is completely different. It provides no imported targets, it just sets variables SDL2_INCLUDE_DIRS, SDL2_LIBRARIES. This config file is harder to use, it requires more lines to be written in a project's CMakeLists.txt, and these lines are completely different from those ones which are required for the good "SDL2Config.cmake" made from source with CMake.

VCPKG provides a good "SDL2Config.cmake". Is it possible to put the good "SDL2Config.cmake" file to a debian package too?
Comment 1 Harry Wagstaff 2018-04-17 10:35:39 UTC 
I'd just like to point out that I've just experienced the exact opposite problem.

I'm working on a project which has SDL as a dependency, and it no longer builds with SDL 2.0.8 since it includes the imported targets rather than the legacy variables. This is essentially a breaking change for any project that uses SDL2 and cmake.

Really, I think that this is an issue with cmake rather than SDL (since the entire design of cmake seems to be constantly in flux).
Comment 2 Tim Aitken 2018-05-20 05:14:18 UTC 
I have a similar problem to the one originally reported. In my case I believe SDL is correctly located by my build, but the version cannot be resolved. When I build the packages myself or with vcpkg it contains the package-import version which behaves as expected.

I believe these files should be included with the distributed package. In response to Harry's comment, the legacy variables should also be added to the CMakeTargets.cmake to support backwards-compatibility with pre-2.8 cmake builds reliant on variables.
Comment 3 Leonardo 2018-05-28 15:47:40 UTC 
The problem is that sdl2-config.cmake is generated when building via the autotools (automake/configure/etc) path and it is not up to date with modern CMake. It is a workaround since CMake folks advised me to not create and submit a FindSDL* file but rather make SDL itself provide a config file (see [1]).

This config file must be modernized, I'm sure a patch would be welcome.


[1]: https://cmake.org/Bug/view.php?id=14826
Comment 4 Leonardo 2019-04-13 19:00:24 UTC 
Oi. I have created bug 4597 that should fix your issue (it creates targets SDL and SDLmain, I couldn't create ALIAS targets on IMPORTED targets). Would you mind giving the new sdl2-config.cmake a try and reporting back if it works?

Thanks.
Comment 5 alexander.grund 2020-02-07 15:22:49 UTC 
@Harry Wagstaff The best solution would be to provide uniform configs for autotools and CMake. I'd even go as far and drop autotools completely as CMake can do the same and more (e.g. cross-platform) and using CMake only relieves from the burden of having to maintain multiple versions of the same code.

For your use case one could provide targets AND the variables with the paths
Comment 6 Matt Scheirer 2020-04-19 16:17:35 UTC 
This will start to become a rising problem in distro packaging - some distros build SDL via autotools while at least Arch uses CMake. As SDL2 based projects switch to using config to find SDL (Debian has been actively proposing patches to several games in recent months to drop FindSDL modules) new releases are failing on Arch.

For now I'm just injecting manual patches to use the SDL2 target in my Arch packages. A possible stopgap would be to insure the cmake built config exports SDL2_INCLUDE_DIRs and SDL2_LIBRARIES to have backwards compatibility with the hand written config. That doesn't fix the problem - tons of software would then start using these variables rather than the SDL2 target - but it would stop software from breaking when moving between the two SDL build types.
Comment 7 alexander.grund 2020-04-20 07:03:10 UTC 
So now that the autotools build provides the targets we need the CMake build to provide the variables?

In the spirit of education I would choose to not do so and force users to use the targets when they are available. Yes this may break stuff but it is easy enough to fix and the right thing to do. And it creates pressure to actually do that.

So the message would be: Want to support newer SDL2 versions? Use the targets!

If you really must provide variables, set them like this:

set(SDL2_INCLUDE_DIRs "")
set(SDL2_LIBRARIES SDL2::SDL2)

If this breaks projects, they really do nasty stuff they should not.