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

[Alan W. Irwin]

I now have a simple CMakeLists.txt file which demonstrates this is a
general find issue whenever alternate NAMES are specified.

cmake_minimum_required(VERSION 2.8)
project(test NONE)

FIND_LIBRARY(TCL_LIBRARY
   NAMES
   tcl
   tcl86 tcl8.6
   tcl85 tcl8.5
   tcl84 tcl8.4
   tcl83 tcl8.3
   tcl82 tcl8.2
   tcl80 tcl8.0
   )

message(STATUS "TCL_LIBRARY = ${TCL_LIBRARY}")

My system version of the Tcl library is /usr/lib/libtcl8.4.so.

If I set the environment variable CMAKE_LIBRARY_PATH to an empty directory,
then

touch $CMAKE_LIBRARY_PATH/libtcl8.4.so

the result of running cmake in an empty build tree while pointing
to the above file is

-- TCL_LIBRARY = /home/software/test_fake_tcltk/install/lib/libtcl8.4.so

where /home/software/test_fake_tcltk/install/lib is what CMAKE_LIBRARY_PATH
points to.  IOW, CMAKE_LIBRARY_PATH works as expected in this case.

However if you want to use a library name that is numerically less than the
system library name of libtcl8.4.so, e.g.,

mv $CMAKE_LIBRARY_PATH/libtcl8.4.so $CMAKE_LIBRARY_PATH/libtcl8.3.so

then the cmake result is

-- TCL_LIBRARY = /usr/lib/libtcl8.4.so

IOW, CMAKE_LIBRARY_PATH is ignored in this case.

It is very common for the list of alternate names to be in decreasing
version order as in the FindTCL.cmake case and the simple test case above so
what this issue means in practice for such Find modules is that
CMAKE_LIBRARY_PATH cannot be used to access old versions in non-standard
locations.  But that is an important use case for software testers. (This
particular developer needed access to Tcl libraries that were older than his
system versions in order to replicate a bug report and ultimately fix the
issue.)

The only way I can explain the above find behaviour is if the alternate
locations are searched for in an inner loop for each alternate name in an
outer loop. In the interests of giving CMake users convenient deterministic
control over how finds are done shouldn't those two loops be switched? That
would mean the names are searched in the inner loop in each alternate
location specified by the outer loop.

I know this suggested swapping of the two loops constitutes an important
change in find behaviour, but this should be a beneficial change since it
means you could always depend on CMAKE_LIBRARY_PATH or any other of the
standard ways to control alternate search locations for find regardless of
the order of alternate names or the names of libraries in the standard
locations. Furthermore, there must be few if any users that depend on the
present behaviour; why on earth would a build system user want to go out of
their way to set up CMAKE_LIBRARY_PATH or the like on a particular system to
control the version of libraries that are found in the expectation that that
control would fail to work under certain conditions?

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
__________________________