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

[Michael Wild]

+1 from me.

I think it also would simplify FindPython.cmake if I remember correctly. Perhaps an option (e.g. NAMES_FIRST) could be be added to find_{library,path,file,program} to trigger the new behavior. This would maintain backward-compatibility and make things more flexible.

Michael

On 17. May, 2010, at 9:52 , Marcel Loose wrote:

> Hi all,
> 
> Sorry to bump in late in this discussing (Ascension day and all that).
> I've also hit the same problem (see
> http://www.mail-archive.com/cmake@cmake.org/msg27838.html). In this case
> it was related to FindBoost.cmake, but the issue is the same. 
> 
> I would be very much in favour of turning the loop in the different
> cmFind*.cxx files inside out: i.e. loop over the paths in the outer loop
> and over the names in the inner loop. If it turns out this breaks any
> CMake build environments, a policy could be added, though I doubt that
> will be necessary.
> 
> Best regards,
> Marcel Loose.
> 
> 
> On Sat, 2010-05-15 at 11:04 -0700, Alan W. Irwin wrote:
>> 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
>> __________________________