Problems with path search order

[Brad King]

Laurent Montel wrote:
> On Monday 27 March 2006 23:44, Albert Astals Cid wrote:
> 
>>Hi, the attached patch fixes problems i had with cmake not searching my
>>correct libkdecore.so, (it found kde3 libkdecore on /usr/lib64) i think the
>>patch is correct, because if you have kdelibs outside what
>>KDE4_LIB_INSTALL_DIR says you are in deep trouble.
> 
> it's a cmake bugs
> I think that you use cmake from cvs.
> When I revert to 2006-03-17 it works fine
> => patch not necessary (for the moment)

It is not a CMake bug.  The patch *is* necessary.  It's actually a CMake 
feature that was added, and in particular its addition was motivated by 
discussion here.  The new FIND_* commands are meant to work this way.

The old FIND_* behavior is preserved only if 
CMAKE_BACKWARDS_COMPATIBILITY is set to 2.2 or lower, which should never 
be the case for KDE.  This is one of the drawbacks of using the 
development version of a project.  Compatibility for features not 
included in a release is not available.

>>As a suggestion i think it could be good improving cmake so that it is able
>>of using the suggested path as first path and then the other paths in the
>>order mentioned on the man page, i see not sense in letting the "program"
>>provide a path to look for but it beign the least significant path.

There is a reason those paths come last which I'll add to the 
documentation.  You can always switch the order like this:

find_library(FOO_LIBRARY NAMES foo PATHS mypaths NO_DEFAULT_PATH)
find_library(FOO_LIBRARY NAMES foo)

-Brad