CMAKE_PREFIX_PATH vs. CMAKE_[INCLUDE|LIBRARY|PROGRAM]_PATH
Andreas Pakulat
apaku at gmx.de
Fri Oct 8 02:41:23 CEST 2010
On 08.10.10 02:14:31, Ingomar Wesp wrote:
> Hey!
>
> I recently had to learn the hard way that setting
> CMAKE_INCLUDE_PATH,CMAKE_LIBRARY_PATH and CMAKE_PROGRAM_PATH does not result
> in equal behavior than just setting CMAKE_PREFIX_PATH. I attempted to build
> kdebase/workspace and ran into a wall when the build system tried to link some
> plasma engine against my system wide akonadi instead of the locally installed
> one. After some help from #kde-devel, I just set CMAKE_PREFIX_PATH instead of
> the three other variables and the build went through.
>
> I don't know enough about the finer differences between setting all of the
> three variables as opposed to setting just CMAKE_PREFIX_PATH, but if
> CMAKE_INCLUDE_PATH,CMAKE_LIBRARY_PATH and CMAKE_PROGRAM_PATH are indeed
> obsolete and lead to failing builds, then we should definitely state that on
> <http://techbase.kde.org/index.php?title=Development/Tutorials/CMake>.
IMHO, no. If anywhere it should be documented in the cmake docs. We
shouldn't replicate the cmake docs in our techbase. We should only document
in techbase if certain things done with find_package(KDE4) change
documented default behaviour of cmake variables.
I don't know what exact problems you ran into but the CMAKE_INCLUDE&Co_PATH
variables are not deprecated. They're just finer-grained than
CMAKE_PREFIX_PATH which assumes a default-layout under the prefix. And
they're checked _after_ CMAKE_PREFIX_PATH values by the corresponding
find_XXX() functions. But all that is documented in the cmake manual.
Andreas
--
Don't worry. Life's too long.
-- Vincent Sardi, Jr.
More information about the Kde-buildsystem
mailing list