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 pytho
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 speci
+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.
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
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
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
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...
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 p
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
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_LIBRA
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 tc
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
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
13 matches
Mail list logo
