Michael Jansen info at michael-jansen.biz
Mon Aug 16 17:25:53 CEST 2010

Am 16.08.2010 14:38, schrieb Christophe Giboudeaux:
> 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")


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

No it's not. From the documentation.

Specifies a path which will be used by the FIND_XXX() commands. It
contains the "base" directories, the FIND_XXX() commands append
appropriate subdirectories to the base directories. So FIND_PROGRAM()
adds /bin to each of the directories in the path, FIND_LIBRARY() appends
/lib to each of the directories, and FIND_PATH() and FIND_FILE() append
/include . By default it is empty, it is intended to be set by the

So CMAKE_PREFIX_PATH controls how a FindXYZ.cmake file looks for stuff
and CMAKE_MODULE_PATH controls how cmake looks for FindXYZ.cmake files.

>> 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:
> /kde/inst/akonadi:/kde/inst/extragear-network:/kde/inst/kdepim:/kde/inst/kdepimlibs:/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

This part is explained by some magic most people don't know incarnated
by find_package(kde4). Have a look at FindKDE4Internal.cmake lines 592+

Do you btw know that


AFTER find_package kde4 makes all the work done there .... kaputt. It
behaves different to doing it before find_package(KDE4). The line Yuri
proposed would work in both cases.

[ Cue the responses telling that setting CMAKE_MODULE_PATH after
find_package(KDE4) is dumb, senseless and ... ]


More information about the Kde-buildsystem mailing list