[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: Strange commit to FindKDE4Internal.cmake
From:       Alexander Neundorf <neundorf () kde ! org>
Date:       2012-02-20 17:28:43
Message-ID: 201202201828.44017.neundorf () kde ! org
[Download RAW message or body]

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 
/usr/share/cmake-2.8/modules 


...
> 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 
documentation).
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)

Alex
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
[prev in list] [next in list] [prev in thread] [next in thread]