overriding CMAKE_MODULE_PATH

[Maciej Mrozowski]

On Monday 16 of August 2010 14:38:24 Christophe Giboudeaux wrote:
> Hi,
> 
> Le 16/08/2010 12:20, Michael Jansen a écrit :
> > Because it is the right thing to do. The first line overriding it is
> > just plain wrong imho.
> > 
> > 1. CMAKE_MODULE_PATH is documented in cmake at the same level as
> > CMAKE_PREFIX_PATH as a variable that changes behaviour. Which means a
> > user can and will expect he is able to override it. Which will break
> > with the first line.
> 
> This is incorrect, CMAKE_PREFIX_PATH is an environment variable and
> CMAKE_MODULE_PATH is a CMake parameter
> (http://public.kitware.com/Wiki/CMake_Useful_Variables : _MODULE belongs
> to the "Locations" section and _PREFIX is under "Environment Variables")

Minor nitpick - CMAKE_PREFIX_PATH is *also* environmnent variable (it's CMake 
parameter in first place).

> > 2. KDE installs a ton of useful not kde related FindXYZ*.cmake files
> > into a path != /usr/share/cmake... . If a non kde project wants to use
> > it (even a small homegrown project) the user has to set
> > CMAKE_MODULE_PATH from the outside. Therefore he needs the line from
> > Yury in his CMakeLists.txt. Since we as kde are the poster child for
> > cmake usage we should implement our cmake files as examples for other to
> > copy.
> 
> This is exactly what CMAKE_PREFIX_PATH does: give the order in which
> CMake looks for stuff. There's no need for this hack.

Not really, CMAKE_PREFIX_PATH does not control CMAKE_MODULE_PATH. It controls
CMAKE_INCLUDE_PATH, CMAKE_PROGRAM_PATH and CMAKE_LIBRARY_PATH - locations that 
find_file, find_library and find_program are aware of - not find_package.

CMAKE_MODULE_PATH is responsible for lookup location of FindXXX.cmake files - 
find_package call.

So, CMAKE_PREFIX_PATH determines which locations will be searched for 
particular dependencies, CMAKE_MODULE_PATH determines which locations will be 
searched for CMake modules responsible for finding those dependencies (what is 
OP's post about).

Imho, KDE SC buildsystem should *not* allow user-supplied CMAKE_MODULE_PATH 
locations - it can only provide yet another way to break compilation (like 
user-supplied stuff in /usr/local shadowing eveything else).

> > 3. If someone develops a small lib he plans to add as a kde dependency
> > he probably installs it into some non distro prefix so he doesn't need
> > root rights to install it. So he needs to override CMAKE_MODULE_PATH in
> > say koffice to make it pick up that location. And i would expect it to
> > work. Remember that his KDELIBS_PREFIX could be distro provided and
> > koffice is installed into /usr/local/ .
> 
> Once again, CMAKE_PREFIX_PATH is enough. Here's an example:
> 
> # echo $CMAKE_PREFIX_PATH
> /kde/inst/akonadi:/kde/inst/extragear-network:/kde/inst/kdepim:/kde/inst/kd
> epimlibs:/kde/inst/kdepim-runtime:/kde/inst/pim
> 
> and CMake ran in kdenetwork has no problem to find libktorrent:
> 
> -- Found libktorrent: /kde/inst/extragear-network/lib64/libktorrent.so
> 
> WRT to the original post, there are two issues:
> - libktorrent should not install FindKtorrent.cmake since it's supposed
> to help finding libktorrent and not ktorrent,
> 
> - It should install a LibKtorrentConfig.cmake instead of a FindXXX.cmake
> for the reasons Andreas already gave.

This.

Also if it wasn't clear already - package X depending on KDE4 ${version} 
(find_package(KDE4 ${version}) can rely on any .cmake file provided by 
kdelibs-${version} and below.

That being said - no FindYYY.cmake file that is already provided by kdelibs 
should be used (unless FindYYY.cmake is broken or insufficient).

In any other cases - when kdelibs doesn't provide required FindYYY.cmake flle, 
package X is required to provide its own private copy of FindYYY.cmake - which 
must not be installed because it would break other packages relying on 
kdelibs-supplied FindYYY.cmake module.

-- 
regards
MM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100816/842b11c3/attachment.sig