CMAKE_PREFIX_PATH vs. CMAKE_[INCLUDE|LIBRARY|PROGRAM]_PATH

[Ingomar Wesp]

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

I agree. However, we probably shouldn't recommend build settings that do not 
work, either.

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

You might have guessed that I'm not too familiar with cmake, so let me outline 
the problem I ran into:

I tried to build and install the following from trunk in the following 
sequence: phonon, kdesupport/soprano, kdesupport/akonadi, kdesupport/attica, 
kdelibs, kdepimlibs, kdebase.

For all of them I used a custom CMAKE_INSTALL_PREFIX pointing to some 
$DESTDIR. Correspondingly, I set CMAKE_INCLUDE_PATH to $DESTDIR/include and 
CMAKE_LIBRARY_PATH to $DESTDIR/lib.

When building kdebase, the correct akonadi headers were found, but the linker 
tried to link against my global akonadi instead of the one installed in 
$DESTDIR, which failed since my globally installed akonadi version is too old.

After having searched for the reason for a quite some time I asked on #kde-
devel and was told that CMAKE_INCLUDE_PATH and CMAKE_CMAKE_LIBRARY_PATH were 
obsolete and should not be used. Instead, I should just set CMAKE_PREFIX_PATH 
to $DESTDIR, which led to a build that ran through nicely.

So there are (at least) the following possible reasons for the experience I 
had:

1.) I messed up and missed some visible piece of documentations that clearly 
    states why what I tried can't work. My bad, but maybe we should take 
    care of pointing this out where we currently state setting just 
    LIB, INCLUDE and PROGRAM paths is ok.

2.) I've done something wrong somewhere else or I'm experiencing unexpected 
    behavior thdddat isn't reproducible. In this case it's just me...

3.) There's a bug somewhere in the toolchain or the makros.

In any case, if the problem exists for others as well, I still think we should 
put up a warning on the respective techbase page, so others won't have to make 
the same experience as I did.

Best regards,
Ingo