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

[Alan W. Irwin]

I have just found another example of the same issue.  A PLplot developer
complained CMake would not find his special python executable.  The relevant
code in FindPythonInterp.cmake contains these alternate names for the python
executable in FIND_PROGRAM

   NAMES python2.6 python2.5 python2.4 python2.3 python2.2 python2.1
python2.0 python1.6 python1.5 python

The experimental python version used the name "python" for the executable,
but his system had python2.6 so FindPythonInterp.cmake always found the
system version no matter how he manipulated the SUPER_PATH.

I expect a lot of those building their own special versions of software are
coping with this CMake bug by screwing around with NAMES order in Find
modules as in Luigi Calori's recent post or by creating symlinks (what I
suggested to the PLplot developer to work around the issue).  However, these
are only stop-gap measures so it appears there is some urgency to getting
bug 0010718 fixed.

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
__________________________