[CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl

[Alan W. Irwin]

On 2010-05-15 09:43-0400 Bill Hoffman wrote:

> OK, your right, it does prefer names that show up first in the name list even 
> if they are later in the total path.
> [...] Not supper easy to fix...   FindProgram is actually a pretty complicated 
> function.
> But, if someone wants to test/send a patch... :)

My C++ skills are too limited to help here, but I believe swapping the
bodies of the "inner" and "outer" FindProgram methods should do the trick
along with the change that the new outer method (formerly the old inner
method) iterates over all names to call the new inner method.

>
> Might break something, but I doubt it.  If you have two copies of something 
> on a machine, you are bound to make someone unhappy some of the time by 
> picking the wrong one...

Well ordinary users tend not to change the order of NAMES that typically
occur in Find modules.  However, they do know how to manipulate the
SUPER_PATH (the collection of all CMake path variants under the control of
the CMake user).  Thus, I doubt anybody will complain once this fix gives
them more complete control of what is found via manipulation of the
SUPER_PATH.

Now that we are in agreement there is an issue with NAMES order determining
the FIND_XXX result rather than whichever NAMES alternative is highest in
the SUPER_PATH, I have written up this issue as bug
http://public.kitware.com/Bug/view.php?id=10718.  I have also done some
additional experiments with variations on the CMakeLists.txt file there to
show that FIND_FILE, FIND_LIBRARY, and FIND_PATH all have the same issue as
FIND_PROGRAM.  My knowledge of the CMake code base and my C++ skills are too
limited to discover where in the CMake codebase the inner and outer loops
for NAMES and SUPER_PATH components should be swapped for those commands,
but thanks for determining that location for the FIND_PROGRAM
command.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________