Strange commit to FindKDE4Internal.cmake

Alexander Neundorf neundorf at
Mon Feb 20 17:28:43 UTC 2012

On Sunday 19 February 2012, Ralf Habacker wrote:
> Am 19.02.2012 22:45, schrieb Pau Garcia i Quiles:
> > 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 

Really ?
My original 2.8.3 binary package as provided by Kitware installs into 

> following this scheme it would be required to add
> ${CMAKE_INSTALL_PREFIX}/share/cmake/official3rdpartymodule.
> KDElibs on windows installs it Find... scripts in

Replace officual3rdpartymodule/ with extra-cmake-modules/ and you have it.

> ${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules, should 3rdparty
> packages be installed into that dir too ?

No. Looking back, it wasn't a very good idea to start installing Find-modules, 
because people started to think this is a good and normal thing to do.
In general, don't ever install Find-modules (except maybe somewhere as 
Either upstream to cmake, or (in the future), upstream to extra-cmake-modules.

And if your package installs a Config.cmake file, the Find-module (which I 
still recommend also in this case) becomes trivial:

find_package(Foo NO_MODULE)
find_package_handle_standard_args(Foo CONFIG_MODE)


More information about the Kde-buildsystem mailing list