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 2464 - Configure a sdl2-config.cmake.in together with sdl2.pc.in
Summary: Configure a sdl2-config.cmake.in together with sdl2.pc.in
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: build (show other bugs)
Version: 2.0.3
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-26 03:47 UTC by Leonardo
Modified: 2019-04-13 23:23 UTC (History)
5 users (show)

See Also:

Attachments
Configure and install sdl2-config.cmake (2.69 KB, patch)
2014-04-06 19:37 UTC, Leonardo 		Details | Diff
Input file for generating sdl2-config.cmake (336 bytes, text/plain)
2014-04-06 19:38 UTC, Leonardo 		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 Leonardo 2014-03-26 03:47:53 UTC 
Despite having a CMakeLists.txt file, SDL2 seems to be mainly built using the autotools system by package-managers. It is nice to have it but it is only useful if you are building SDL2 by yourself. 

People that want to use CMake to find their already-installed SDL2 are using a FindSDL2.cmake module based on the old FindSDL.cmake. This is not deprecated but it is discouraged by the CMake devs (see http://www.cmake.org/Bug/view.php?id=14826), as these modules needs maintainers to be included in the official CMake installation.

To fix that, SDL and its accompanying libraries could configure a simple sdl2-config.cmake file, much like it does with sdl2.pc.in. We don't need to configure a full sdl2-config.cmake as in this post, http://forums.libsdl.org/viewtopic.php?t=10068&sid=ccf8abbf0d73fb03ae9cded991e60959 (because it depends on it being built with CMake). Using something as simple as http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Configuration_Files is deemed enough. Here is another: http://quickgit.kde.org/?p=prison.git&a=blob&f=lib%2Fprison%2FPrisonConfig.cmake.in

I could have done this myself and submitted a patch but I don't have any skills with autotools. It seems to me that the variables we need to configure are somewhat the same in sdl2.pc.in, so maybe ./configure can do it?

Thanks in advance.
Comment 1 Leonardo 2014-03-26 03:53:13 UTC 
We would also need a sdl2-version.cmake, but I think that would be as easy as sdl2-config.cmake to configure.

The links I provided have more information on them.
Comment 2 Leonardo 2014-04-06 19:37:33 UTC 
Created attachment 1607 [details]
Configure and install sdl2-config.cmake
Comment 3 Leonardo 2014-04-06 19:38:04 UTC 
Created attachment 1608 [details]
Input file for generating sdl2-config.cmake
Comment 4 Leonardo 2014-04-06 19:39:32 UTC 
Here is a basic sdl2-config.cmake.in and a changeset that configures and installs it.

I've tested with cmake --find-package mode and it is properly working.

There is a way of producing a sdl2-config.cmake that is prefix-independent, but since users are already relying on pkgconfig (which is prefix-bound), I am not sure if its a good idea.
Comment 5 Jean-Pierre Gygax 2014-07-13 22:30:28 UTC 
I support this request (thanks, Leonardo, for bringing this up). but I do have a related suggestion/question.

I'm still a beginner with CMake, so it's quite possible that I'm misunderstanding something here. However, in one of my own projects, I have used the following combination to make my library available to other CMake projects without having to use the install() commands:

---------------
export(TARGETS ${PROJECT_NAME} FILE ${CMAKE_BINARY_DIR}/${PROJECT_NAME}-config.cmake)
export(PACKAGE ${PROJECT_NAME})
---------------

In a dependent CMake-managed project, I can then use the following to access my library (called "LSApplication"):

--------------------
find_package(LSApplication CONFIG REQUIRED)
target_include_directories(${PROJECT_NAME} PRIVATE $<TARGET_PROPERTY:LSApplication,INTERFACE_INCLUDE_DIRECTORIES>)
target_link_libraries(${PROJECT_NAME} LSApplication)
---------------------

I made this work through much experimentation. But unless I made some mistake, this is the simplest way to mesh together CMake-based projects.

(I'm using CMake 3.0 btw, having started using CMake very recently.)
Comment 6 Leonardo 2014-07-15 20:05:15 UTC 
(In reply to Jean-Pierre Gygax from comment #5)
> I support this request (thanks, Leonardo, for bringing this up). but I do
> have a related suggestion/question.
> 
> I'm still a beginner with CMake, so it's quite possible that I'm
> misunderstanding something here. However, in one of my own projects, I have
> used the following combination to make my library available to other CMake
> projects without having to use the install() commands:
> 
> ---------------
> export(TARGETS ${PROJECT_NAME} FILE
> ${CMAKE_BINARY_DIR}/${PROJECT_NAME}-config.cmake)
> export(PACKAGE ${PROJECT_NAME})
> ---------------
> 
> In a dependent CMake-managed project, I can then use the following to access
> my library (called "LSApplication"):
> 
> --------------------
> find_package(LSApplication CONFIG REQUIRED)
> target_include_directories(${PROJECT_NAME} PRIVATE
> $<TARGET_PROPERTY:LSApplication,INTERFACE_INCLUDE_DIRECTORIES>)
> target_link_libraries(${PROJECT_NAME} LSApplication)
> ---------------------
> 
> I made this work through much experimentation. But unless I made some
> mistake, this is the simplest way to mesh together CMake-based projects.
> 
> (I'm using CMake 3.0 btw, having started using CMake very recently.)

Well, that also works, but both of your projects are using CMake already and built using them as build system. SDL2, most of the time (including major distro builds) is built using autotools, which doesn't create the files created by the export() commands you mentioned.

This patch address that by having a file that can be configured and installed by the autotools system, making it easly available to CMake projects.

I appreciate your support :)
Comment 7 Jean-Pierre Gygax 2014-07-15 20:12:02 UTC 
Thanks for the response. What I meant was: why not use this method instead of creating config (and possibly version) files?
Comment 8 Daniel Gibson 2015-05-07 13:29:45 UTC 
using SDL2 in programs using cmake is a pain currently (because everyone has to ship a hacked FindSDL2.cmake).

this patch should improve the situation, so I hope it gets merged
Comment 9 Martin Gerhardy 2015-05-08 20:11:58 UTC 
+1 from my side, too. it would make my life a lot easier.
Comment 10 Jan Henke 2015-06-29 14:25:20 UTC 
This is really needed. CMake is the tool of choice for many consumers of SDL2, while at the same time on of few major projects not providing a out-of-the-box way to configure CMake. Please consider inclusion of this patch.
Comment 11 Sam Lantinga 2015-06-30 05:24:31 UTC 
This has been applied for 2.0.4, thanks!
https://hg.libsdl.org/SDL/rev/6e87ae760e6d