On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf <neund...@kde.org> wrote:
> CMake searches in a set of self-defined standard locations, as documented in > the find_package() section of the man page. > I don't have experience with this myself on Windows, but doesn't this make it > kind of work ? No, it does not. On Windows there are absolutely no standards for anything. Most people will have development libraries and headers outside path. Several of them. Something like this, for instance: C:\dev\myproject\3rdparty\include C:\dev\myproject\3rdparty\lib C:\kitware\vision\include C:\kitware\vision\lib c:\tmp\devellopmentlibraries\msvc2010\libpng\include c:\tmp\devellopmentlibraries\msvc2010\libpng\lib ... Now try and find a LibFooConfig.cmake somehow. Absolutely impossible. Heck, many times headers and libraries will be under some shared network drive! (something like H:\lib + H:\include). Are you going to scan every drive connected to the computer looking for config files? >> If TheGreatApp does a find_package(LibFoo REQUIRED) this is what happens: >> >> - If LibFooConfig.cmake and/or FindLibFoo.cmake is available (either >> from CMake itself or bundled with my *application* in >> TheGreatApp/cmake), either LibFoo is found and all goes well, or >> LibFoo is not found and the error the user will see is "LibFoo not >> found" because either LibFooConfig.cmake or FindLibFoo.cmake would >> provide what find_package needs (configuration and/or module). >> >> - If LibFooConfig.cmake is installed on Windows but it's on a path >> CMake does not look into (the *norm* on Windows), or if I do not >> bundle FindLibFoo.cmake with my application, this is the error a user >> would see on Windows: an incomprehensible error. Same error as if >> LibFooConfig.cmake is not available. >> >> I cannot see the advantage of LibFooConfig.cmake on non-Unix >> platforms, or even on Unix platforms when libraries (including >> FooConfig.cmake) is installed on non-standard locations. It will make >> find_package fail at the very first step (trying to locate >> FooConfig.cmake or FindLibFoo.cmake) without even delving into the >> very finding operation. > > We are discussing exactly this currently on the cmake-developers list. > > My proposal for cmake 2.8.8 is: > > find_package(Qt5) > > only uses FindQt5.cmake (and doesn't look for a Qt5Config.cmake), and if > FindQt5.cmake is not found, it says: > ----------------------------------------------- > "CMake Error at CMakeLists.txt:7 (find_package): > Could not find module FindQt5.cmake. > > Adjust CMAKE_MODULE_PATH to find FindQt5.cmake. > > FindQt5.cmake must either be part of this project itself, in this case > adjust CMAKE_MODULE_PATH so that it points to the correct location inside > your source tree. > > Or it must be installed by a package which has already been found via > find_package(). In this case make sure that this package has indeed been > found and adjust CMAKE_MODULE_PATH to contain the location where that > package has installed FindQt5.cmake. This must be a variable provided by > that package or something similar, i.e. for instance not your current > CMAKE_INSTALL_PREFIX. This error in general means that you are relying on > a Find-module without ensuring that this Find-module exists." > > ----------------------------------------------- > > OTOH > find_package(Qt5 NO_MODULE) > will look only for a Qt5Config.cmake, i.e. you have to enforce Config mode, > and thus make is possible for cmake to generate better error messages, and so > for the user to know better what went wrong: > > ----------------------------------------------- > "CMake Error at CMakeLists.txt:7 (find_package): > Could not find a configuration file for package Qt5 with one of the > following names: > > Qt5Config.cmake > qt5-config.cmake > > To find the configuration file, set CMAKE_PREFIX_PATH to the installation > prefix of Qt5, or set Qt5_DIR to the directory containing a CMake > configuration file for Qt5. > " > ----------------------------------------------- > > > What do you think about this ? That looks wrong to me. IMHO: - find_package must always look for LibFooConfig.cmake before looking for FindLibFoo.cmake - Libraries may install a LibFooConfig.cmake. The only advantage in a LibFooConfig.cmake is it would provide faster discovery for the "system-wide" libfoo (no need for all the checks, header parsing, etc that usually takes place in FindLibFoo.cmake) - Third party applications must always include a FindLibFoo.cmake in TheGreatApp/cmake and adjust CMAKE_MODULE_PATH conveniently to use it. - Libraries (libfoo) must always provide a reference FindLibFoo.cmake in the package and make it available for third party developers in the tarballs. Packages (libfoo-dev) must install this to a place that is searched for by CMake: some equivalent to /usr/share/cmake-2.8/Modules, but for *official* 3rd-party FindLibFoo.cmake modules (i. e. modules provided by the library itself, not modules written by a third party) The search order would be like this: 1. LibFooConfig.cmake 2. FindLibFoo.cmake in CMAKE_MODULE_PATH 3. FindLibFoo.cmake in /usr/share/cmake/official3rdpartymodules 4. FindLibFoo.cmake in /usr/share/cmake-2.8/Modules On Windows, (3) would probably be something like %CommonProgramFiles%\CMake\official3rdpartymodules That's a first write-up and I'm probably missing some case but you get the idea. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem