From kde-buildsystem Sun Feb 19 21:45:00 2012 From: Pau Garcia i Quiles Date: Sun, 19 Feb 2012 21:45:00 +0000 To: kde-buildsystem Subject: Re: Strange commit to FindKDE4Internal.cmake Message-Id: X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=132968795508810 On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf wrot= e: > 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 mak= e 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): > =A0Could not find module FindQt5.cmake. > > =A0Adjust CMAKE_MODULE_PATH to find FindQt5.cmake. > > =A0FindQt5.cmake must either be part of this project itself, in this case > =A0adjust CMAKE_MODULE_PATH so that it points to the correct location ins= ide > =A0your source tree. > > =A0Or it must be installed by a package which has already been found via > =A0find_package(). =A0In this case make sure that this package has indeed= been > =A0found and adjust CMAKE_MODULE_PATH to contain the location where that > =A0package has installed FindQt5.cmake. =A0This must be a variable provid= ed by > =A0that package or something similar, i.e. =A0for instance not your curre= nt > =A0CMAKE_INSTALL_PREFIX. =A0This error in general means that you are rely= ing on > =A0a 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 mod= e, > and thus make is possible for cmake to generate better error messages, an= d so > for the user to know better what went wrong: > > ----------------------------------------------- > "CMake Error at CMakeLists.txt:7 (find_package): > =A0Could not find a configuration file for package Qt5 with one of the > =A0following names: > > =A0 =A0Qt5Config.cmake > =A0 =A0qt5-config.cmake > > =A0To find the configuration file, set CMAKE_PREFIX_PATH to the installat= ion > =A0prefix of Qt5, or set Qt5_DIR to the directory containing a CMake > =A0configuration 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