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