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

[Marcel Loose]

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
> __________________________
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake