|
Notes |
|
|
(0035480)
|
|
Brad King
|
|
2014-03-24 08:37
|
|
|
|
|
(0035488)
|
|
Leonardo
|
|
2014-03-24 13:22
|
|
|
|
|
(0035490)
|
|
Brad King
|
|
2014-03-24 13:41
|
|
Re 0014826:0035488: It is impractical for CMake to supply a find module for every package in the world and keep up with development on each one. CMake-aware packages should take the time to supply a CMake package configuration file, much like ".pc" files are provided for pkgconfig.
For example, Qt5 and LLVM both have non-CMake build systems but still supply a CMake package configuration file. |
|
|
|
(0035502)
|
|
Leonardo
|
|
2014-03-24 23:11
|
|
Yes, I agree with you that it is impractical to keep track of every package in the world, but that is not what this bug report is about. It is about SDL2 and its side libraries. It is also not to keep track of SDL2 development. I am sorry if appeared to be like that.
The point of being open-source is to let users contribute. A simple 'FindSDL2' on google will show how many people are coming up with their own solutions, they just hadn't filed a bug report here yet. You don't have to keep track of SDL2 development, we (the community) will do it for you. I already have supplied some of what could be a FindSDL2.cmake that can be a base for inclusion on CMake Modules. Later if it breaks, we will file a bug, just as I am doing it now, and someone might come up with a solution. Don't worry, the community is already making it happen. We enjoy using CMake, all I want is to make it better.
What is the harm in it?
There is work going on to provide those config files for SDL2 but it is much as open-source as is CMake in this particular regard. I just though that work on CMake-end of it would be faster because of the already existing FindSDL*.cmake and the user provided FindSDL2*.cmake ones.
On a side question, why are you against this if CMake already *has* FindSDL.cmake? Do you see them as a mistake? Why have a lot of official Find*.cmake and not accept users asking to include others? I don't see a deprecation note on the link you provided about the find-module way of finding packages, so I guess they are still the way to go on packages that don't provide package config yet.
In my point of view, the FindSDL2.cmake module would only bring benefit to CMake and potential CMake + SDL2 users. |
|
|
|
(0035508)
|
|
Brad King
|
|
2014-03-25 15:19
|
|
Re 0014826:0035502: I'm not outright opposed to FindSDL2 modules, but:
(a) Package configuration files that come with the package are technically superior to find modules because they know exactly what comes with the package and where it is located. Find modules have to locate things piecemeal and may get mismatched headers and libraries.
(b) Is "SDL2" really a different package from "SDL" version 2? The find_package command has support for version requests, so the existing FindSDL modules could be taught to honor "find_package(SDL 2)".
FYI, our policy on find module contributions is documented here:
http://www.cmake.org/Wiki/CMake:Module_Maintainers [^] |
|
|
|
(0035515)
|
|
Leonardo
|
2014-03-25 21:55
(edited on: 2014-03-25 21:56) |
|
Oh, I am sorry, I wasn't aware of those policies. I think it should go not in the wiki but somewhere easier, in the official docs maybe.
Those policies are totally reasonable and I quite agree with them. I wouldn't be opening this report if I knew them before.
SDL2 is really a different and incompatible package from SDL. For instance, SDL2 has a different .so/.dll name (libSDL2.so) and a different API in many ways. find_package(SDL) should by no means report SDL_FOUND if the version found is SDL 2, not SDL 1.2.
I'll take these informations to the SDL community and see if someone wants to volunteer as a maintainer for FindSDL2*.cmake or to improve CMake support in SDL2 and its libraries.
Thanks.
|
|
|
|
(0042513)
|
|
Kitware Robot
|
|
2016-06-10 14:29
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|