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")
http://cmake.org/cmake/help/cmake-2-8-docs.html#section_Variables%20That%20Change%20Behavior > >> 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 project. See also CMAKE_SYSTEM_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH. 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: > > # echo $CMAKE_PREFIX_PATH > /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+ (here). Do you btw know that set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules) 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 ... ] Mike _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
