[CMake] Possible bugs in search order with NAMES option

[Chris Foster]

Hi all,

I've spotted a possible bug the way that multiple names interact with the
search path order.  This is with the current CVS version of cmake.

Suppose I have two versions of a library installed in different places on my
system:

/usr/lib/libA.so    <-- happens to be libA-1.0.so

and

/funky/location/lib/libA_2_0.so    <-- version 2.0


(The boost libraries tend to be named with suffixes like this which is the
reason I've got problems)


Now, the people who wrote the FindA.cmake know about the various names, and
have written something that amounts to

find_library(A_LIBRARY
    NAMES A A_2_0
)

in FindA.cmake


If I want to make sure that the more recent version of libA (which is
installed in /funky/location) is found first, I'd expect to do something like

set(CMAKE_LIBRARY_PATH /funky/location/lib ${CMAKE_LIBRARY_PATH})

since according to the 2.6.4 documentation for find_library(),
CMAKE_LIBRARY_PATH is the first place where libraries are searched for.
However, in this case it seems that cmake is still finding /usr/lib/libA.so
instead.


Looking at cmFindLibraryCommand::FindNormalLibrary(), I see something like

for(name in Names)
{
    for(path in SearchPaths)
    {
        <find name in path; if found return it, if not continue>
    }
}

Because A is listed before A_2_0 in the NAMES option to find_library(),
libA.so is searched for in all paths (including the standard system path
/usr/lib) *before* going on to look for libA_2_0.so.  This seems wrong to me,
but is it?  How can I override the search paths correctly in this case?

Attached is a simple patch for cmFindLibraryCommand::FindNormalLibrary()
against current cvs which swaps the orders of the loops.


Unfortunately there are other instances of the same potential problem
scattered around the cmake source, and I haven't got the time to track all of
them down and fix them.  Grepping for '\<Names\>' turns up some suspects:

* cmFindLibraryCommand::FindFrameworkLibrary()
* SystemTools::FindProgram()  (the multi-name version)
* cmFindPathCommand::FindNormalHeader()
* cmFindPathCommand::FindFrameworkHeader()


So, bug or no?  Perhaps I did something stupid :)

Thanks,
~Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: find_library_names_order.patch
Type: application/octet-stream
Size: 1360 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20091010/db10b2c1/attachment.obj>