[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic