1
General / Re: cmake 3.0: Config-file Packages
« on: December 23, 2014, 01:56:03 am »
Ok, so I forked SFML and made a first attempt to implement config file packages. You can find a first version here. I have tested it with the example code from the docs and the following CMakeLists.txt:
That works fine with windows and linux (archlinux), but linux was not able to find the local exported build tree, although it was registered in the user package registry (on windows this works fine). I also made an attempt to achieve backward compatibility (here). When the the sfml-config.cmake is found it also includes the FindSFML.cmake, so that all classic variables are set and the following CMakeLists.txt is still possible:
However, there are a few problems I ran into:
- Because targets are named sfml-<comp>, all exported targets will be called sfml::sfml-<comp>. I haven't figured out a way to name them sfml::<comp>, like sfml::graphics
- The external dependencies are kinda problem. Currently they are linked privately, so that they won't be listed in the exported targets. However... static linking is then not possible. In the backward-compatibility branch i tried to add the dependencies to the targets manually, after they were found by FindSFML.cmake. In another branch I have tried to import all external dependencies as imported libraries and install them along the sfml libraries, but that does not work (cmake does not allow to install imported taregts). This solution would be very nice, because we could get rid of the OS-dependent install section in the main cmake and all other problems with external libraries.
- I don't knwo how to handle components... I think it makes no sense to treat them specially, because sfml-targets.cmake will only contain components that are present anyway. One could however add a check to test if all given components are present.
- I don't know if backward-compatibility is possible when using the exported local build. Because there is not the classic directory structure, that FindSFML.cmake expects. We would have to change FindSFML.cmake and I do not want to do that
- I have not looked at versioning for now
- I have not and can not test it under ios, because I don't have a mac^^ ( ohh maybe I could download a VM...)
Maybe you can list a few criteria, that must be fulfilled, to merge back. Also leave a comment on the code style.
Code: [Select]
cmake_minimum_required(VERSION 2.8)
project(sfml-test)
find_package(SFML COMPONENTS audio system graphics window REQUIRED)
add_executable(sfml-test test.cpp)
target_link_libraries(sfml-test
sfml::sfml-system
sfml::sfml-graphics
sfml::sfml-window
sfml::sfml-audio)
That works fine with windows and linux (archlinux), but linux was not able to find the local exported build tree, although it was registered in the user package registry (on windows this works fine). I also made an attempt to achieve backward compatibility (here). When the the sfml-config.cmake is found it also includes the FindSFML.cmake, so that all classic variables are set and the following CMakeLists.txt is still possible:
Code: [Select]
cmake_minimum_required(VERSION 2.8)
project(old-sfml-test)
find_package(SFML COMPONENTS audio system graphics window REQUIRED)
include_directories(${SFML_INCLUDE_DIR})
add_executable(old-sfml-test test.cpp)
target_link_libraries(old-sfml-test ${SFML_LIBRARIES})
However, there are a few problems I ran into:
- Because targets are named sfml-<comp>, all exported targets will be called sfml::sfml-<comp>. I haven't figured out a way to name them sfml::<comp>, like sfml::graphics
- The external dependencies are kinda problem. Currently they are linked privately, so that they won't be listed in the exported targets. However... static linking is then not possible. In the backward-compatibility branch i tried to add the dependencies to the targets manually, after they were found by FindSFML.cmake. In another branch I have tried to import all external dependencies as imported libraries and install them along the sfml libraries, but that does not work (cmake does not allow to install imported taregts). This solution would be very nice, because we could get rid of the OS-dependent install section in the main cmake and all other problems with external libraries.
- I don't knwo how to handle components... I think it makes no sense to treat them specially, because sfml-targets.cmake will only contain components that are present anyway. One could however add a check to test if all given components are present.
- I don't know if backward-compatibility is possible when using the exported local build. Because there is not the classic directory structure, that FindSFML.cmake expects. We would have to change FindSFML.cmake and I do not want to do that
- I have not looked at versioning for now
- I have not and can not test it under ios, because I don't have a mac^^ ( ohh maybe I could download a VM...)
Maybe you can list a few criteria, that must be fulfilled, to merge back. Also leave a comment on the code style.