Strange commit to FindKDE4Internal.cmake

Pau Garcia i Quiles pgquiles at
Sun Feb 19 21:45:00 UTC 2012

On Sun, Feb 19, 2012 at 5:20 PM, Alexander Neundorf <neundorf at> 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:


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."
> -----------------------------------------------
> 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.


- 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

That's a first write-up and I'm probably missing some case but you get the idea.

Pau Garcia i Quiles
(Due to my workload, I may need 10 days to answer)

More information about the Kde-buildsystem mailing list