| Summary: | Configure a sdl2-config.cmake.in together with sdl2.pc.in | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Leonardo <leonardo.guilherme> |
| Component: | build | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | gygax, Jan.Henke, leonardo.guilherme, martin.gerhardy, metalcaedes |
| Version: | 2.0.3 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.libsdl.org/show_bug.cgi?id=4597 | ||
| Attachments: |
Configure and install sdl2-config.cmake
Input file for generating sdl2-config.cmake |
||
|
Description
Leonardo
2014-03-26 03:47:53 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. Created attachment 1607 [details]
Configure and install sdl2-config.cmake
Created attachment 1608 [details]
Input file for generating sdl2-config.cmake
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. 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.)
(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 :) Thanks for the response. What I meant was: why not use this method instead of creating config (and possibly version) files? 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 +1 from my side, too. it would make my life a lot easier. 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. This has been applied for 2.0.4, thanks! https://hg.libsdl.org/SDL/rev/6e87ae760e6d |