Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
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 __ ___ 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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
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.
I think I have got the same problem (bug) as had FindFreetype always
getting system lib even if I a custom version was present in a folder
lib under a path specified in
CMAKE_PREFIX_PATH as the system lib was called freetype while the custom
one was called freetype238 and the module was (erroneously??) setting
NAMES freetype libfreetype freetype219 freetype238
I solved switching to
NAMES freetype238 freetype219 freetype libfreetype
It would be good to have it fixed
Thanks
Here is what the code does:
The ivar this->SearchPaths is the super path in the this function:
std::string cmFindProgramCommand::FindProgram(std::vector
names)
{
std::string program = "";
if(this->SearchAppBundleFirst || this->SearchAppBundleOnly)
{
program = FindAppBundle(names);
}
// this is the main search, it passes in a list of names,
// and the super path
if(program.empty() && !this->SearchAppBundleOnly)
{
program = cmSystemTools::FindProgram(names, this->SearchPaths, true);
}
if(program.empty() && this->SearchAppBundleLast)
{
program = this->FindAppBundle(names);
}
return program;
}
// FindProgram loops over the names and trys to each
// name in the total path
//
kwsys_stl::string SystemTools::FindProgram(
const kwsys_stl::vector& names,
const kwsys_stl::vector& path,
bool noSystemPath)
{
for(kwsys_stl::vector::const_iterator it =
names.begin();
it != names.end() ; ++it)
{
// Try to find the program.
kwsys_stl::string result = SystemTools::FindProgram(it->c_str(),
path,
noSystemPath);
if ( !result.empty() )
{
return result;
}
}
return "";
Not supper easy to fix... FindProgram is actually a pretty
complicated function. But, if someone wants to test/send a patch... :)
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...
-Bill
___
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
___
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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
+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
>> __
___
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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
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 ___ 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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
On 2010-05-15 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. AARGH. That should have read iterates over all paths in the SUPER_PATH to call the new inner method which iterates over all names. 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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
On 5/15/2010 2:04 PM, Alan W. Irwin wrote:
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.
The code is all here:
cmFindProgramCommnad.cxx:
std::string cmFindProgramCommand::FindProgram(std::vector
names)
kwsys/SystemTools.cxx:
kwsys_stl::string SystemTools::FindProgram(
const char* nameIn,
const kwsys_stl::vector& userPaths,
bool no_system_path)
kwsys_stl::string SystemTools::FindProgram(
const kwsys_stl::vector& names,
const kwsys_stl::vector& path,
bool noSystemPath)
{
___
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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
OK, your right, it does prefer names that show up first in the name list
even if they are later in the total path.
Here is what the code does:
The ivar this->SearchPaths is the super path in the this function:
std::string cmFindProgramCommand::FindProgram(std::vector
names)
{
std::string program = "";
if(this->SearchAppBundleFirst || this->SearchAppBundleOnly)
{
program = FindAppBundle(names);
}
// this is the main search, it passes in a list of names,
// and the super path
if(program.empty() && !this->SearchAppBundleOnly)
{
program = cmSystemTools::FindProgram(names, this->SearchPaths, true);
}
if(program.empty() && this->SearchAppBundleLast)
{
program = this->FindAppBundle(names);
}
return program;
}
// FindProgram loops over the names and trys to each
// name in the total path
//
kwsys_stl::string SystemTools::FindProgram(
const kwsys_stl::vector& names,
const kwsys_stl::vector& path,
bool noSystemPath)
{
for(kwsys_stl::vector::const_iterator it =
names.begin();
it != names.end() ; ++it)
{
// Try to find the program.
kwsys_stl::string result = SystemTools::FindProgram(it->c_str(),
path,
noSystemPath);
if ( !result.empty() )
{
return result;
}
}
return "";
Not supper easy to fix... FindProgram is actually a pretty complicated
function. But, if someone wants to test/send a patch... :)
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...
-Bill
___
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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
On 5/13/2010 2:48 PM, Alan W. Irwin wrote: This was by design. The idea was that you find the first copy of something that is in the PATH. The names were not expected to be in any particular order. They were supposed to be equivalent. If it found one good. And, just like PATH it should find the first one that it finds. I think you have just described the behaviour that I want and which I believe most people expect. Search for all names in the first alternate location, then in the second, etc., until you get a hit. But as my simple example demonstrates that is not what has been implemented (at least for FIND_LIBRARY) which is search for the first name in all locations in turn, then continue for the second name, etc., until you get a hit. Then, I described it poorly. :) It will find the first of any of the named things in the PATH. This assumes all names are equally desirable, and if what ever the first one found is good enough. find_program(foo NAMES fooalias1 fooalias2 fooaliase3) This will find the first fooalias in the PATH. What you want is for it to find fooalias1 even if there is a fooalias3 higher in the PATH. That is not what it does... :) -Bill ___ 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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
On 2010-05-13 14:20-0400 Bill Hoffman wrote: On 5/13/2010 2:09 PM, Alan W. Irwin wrote: 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 ) This was by design. The idea was that you find the first copy of something that is in the PATH. The names were not expected to be in any particular order. They were supposed to be equivalent. If it found one good. And, just like PATH it should find the first one that it finds. I think you have just described the behaviour that I want and which I believe most people expect. Search for all names in the first alternate location, then in the second, etc., until you get a hit. But as my simple example demonstrates that is not what has been implemented (at least for FIND_LIBRARY) which is search for the first name in all locations in turn, then continue for the second name, etc., until you get a hit. 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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
On 5/13/2010 2:09 PM, Alan W. Irwin wrote: 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 ) This was by design. The idea was that you find the first copy of something that is in the PATH. The names were not expected to be in any particular order. They were supposed to be equivalent. If it found one good. And, just like PATH it should find the first one that it finds. I guess it could be an option -Bill ___ 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
Re: [CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl
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
__
___
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
