A PLplot developer who is not that familiar with CMake has just reported
that CMAKE_LIBRARY_PATH does not allow him to find the libtcl8.4.so library
that he had built and installed in a special location.
The relevant fragment of code in FindTCL.cmake is the following:
FIND_LIBRARY(TCL_LIBRARY
NAMES
tcl
tcl${TK_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION}
tcl86 tcl8.6
tcl85 tcl8.5
tcl84 tcl8.4
tcl83 tcl8.3
tcl82 tcl8.2
tcl80 tcl8.0
PATHS ${TCLTK_POSSIBLE_LIB_PATHS}
)
The result he obtains with cmake-2.8.1 built from source is cmake finds his
system version (/usr/lib64/libtcl.so) rather than the desired
$CMAKE_LIBRARY_PATH/libtcl8.4.so.
I always felt the effect of the above code fragment would be all NAMES
were searched for in the documented locations in order from
#1 (corresponds in part to the cmake CMAKE_LIBRARY_PATH option), #2
(corresponds in part to the CMAKE_LIBRARY_PATH environment variable)
,..., through #6 (corresponds in part to the PATHS specified above). In
other words the NAMES are run through in the innermost loop and
the locations from #1 to #6 are handled in an outer loop so that libtcl8.4.so
pointed to by CMAKE_LIBRARY_PATH would be found.
However, from the result reported to me, it appears the inner and outer
loops are switched from what I thought so libtcl.so is always found
preferentially if present in the system location regardless of
CMAKE_LIBRARY_PATH.
Is that right? Or is something else going on?
Whatever the cause of this, it seems a rather noxious bug to me if a
developer cannot use CMAKE_LIBRARY_PATH to find libtcl8.4.so in a
non-standard location because of a system version with name libtcl.so.
If the CMake developers also feel this is a strange result and therefore
need more detailed results to help diagnose this, I will try to make a
simplest possible example that anybody can run that shows the issue.
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
