Strange commit to FindKDE4Internal.cmake

Sun Feb 19 22:21:18 UTC 2012

Am 19.02.2012 22:45, schrieb Pau Garcia i Quiles:
> On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf<neundorf at 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/Module
cmake 2.8.3 on linux installs it Find... scripts in /usr/share/cmake/modules
cmake 2.8.7 on windows installs it Find... scripts in 
<install-root>/share/cmake-2.8/Modules

> em  On Windows, (3) would probably be something like
> %CommonProgramFiles%\CMake\official3rdpartymodules
following this scheme it would be required to add   
${CMAKE_INSTALL_PREFIX}/share/cmake/official3rdpartymodule.
KDElibs on windows installs it Find... scripts in 
${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules, should 3rdparty 
packages be installed into that dir too ?

Ralf