View Issue Details [ Jump to Notes ]

[ Print ]

Project

Category

View Status

Date Submitted

Last Update

0010335

CMake

public

2010-02-26 05:56

2011-01-12 07:20

Reporter

Marcel Loose

Assigned To

Brad King

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

CMake-2-8

Target Version

CMake 2.8.4

Fixed in Version

CMake 2.8.4

Summary

0010335: FIND_XXX problem with symlinks when using ENV

Description

I've noticed a problematic behaviour with the FIND_XXX macros when using
ENV in either PATHS or HINTS: symbolic links get converted to the real
paths. This happens with cmake 2.6.x and 2.8.0. Is this a bug?

Here's an example:

$ ls -l /opt/hdf5
lrwxrwxrwx 1 root root 18 2009-09-21 10:08 /opt/hdf5 ->
/data/sys/opt/hdf5

$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(MyHDF5)
set(ENV{HDF5_ROOT} /opt/hdf5)
find_path(HDF5_INCLUDE_DIR hdf5.h
HINTS ENV HDF5_ROOT
PATH_SUFFIXES include)

$ grep HDF5_INCLUDE_DIR CMakeCache.txt
HDF5_INCLUDE_DIR:PATH=/data/sys/opt/hdf5/include

Replacing 'ENV HDF5_ROOT' in find_path() with the literal string
'/opt/hdf5' gives me:

$ grep HDF5_INCLUDE_DIR CMakeCache.txt
HDF5_INCLUDE_DIR:PATH=/opt/hdf5/include

Additional Information

This was discussed on the mailing list, but IMHO, the problem still remains. Here's an excerpt of the last mail.

> > I've noticed a problematic behaviour with the FIND_XXX macros when using
> > ENV in either PATHS or HINTS: symbolic links get converted to the real
> > paths. This happens with cmake 2.6.x and 2.8.0. Is this a bug?
>
> No.
>
> Ok, longer answer: why do you think this is bad ?
>
> Alex

I think it's bad for at least two reasons:

1) Consistency!
It happens when using ENV, but not when hard-coding the exact same path.
See my example, where using "HINTS ENV HDF5_ROOT" (with HDF5_ROOT set to
'/opt/hdf5') resulted in the symlink being converted to a real path,
whereas using "HINTS /opt/hdf5" did not result in a real path.

2) The symlink exists for a reason!
The build is done on a cluster front-end node, which provides access to
third-party software for the compute nodes using NFS. So, for example,
HDF5 resides in the directory '/data/sys/opt/hdf5' on the front-end
node. The compute nodes, however, see this directory as '/opt/hdf5'.
Therefore, on the front node, a symlink "/opt/hdf5
-> /data/sys/opt/hdf5" exists. Translating '/opt/hdf5' into the real
path results in the compute nodes not being able to locate the required
shared libraries.

IMHO, CMake should not mess with symlinks.

Tags

No tags attached.

Attached Files

realpath.patch [^] (658 bytes) 2010-02-26 08:35 [Show Content] [Hide Content]

diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index 1c00621..c3c9f95 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -371,9 +371,7 @@ void SystemTools::GetPath(kwsys_stl::vector<kwsys_stl::string>& path, const char
     kwsys_stl::string::size_type endpos = pathEnv.find(pathSep, start);
     if(endpos != kwsys_stl::string::npos)
       {
-      kwsys_stl::string convertedPath;
-      Realpath(pathEnv.substr(start, endpos-start).c_str(), convertedPath);
-      path.push_back(convertedPath);
+      path.push_back(pathEnv.substr(start, endpos-start));
       start = endpos+1;
       }
     else

Relationships

has duplicate

0011541

closed

Brad King

find_program resolves symbolic links for paths in $PATH

Notes
(0019641) Marcel Loose (developer) 2010-02-26 08:42	The patch 'realpath.patch' fixes the problem of converting symbolic links. Possible problem with this patch: If someone uses a relative path in the environment variable used in the FIND_XXX command, then it may not find XXX, where it previously would. IMHO it's bad practice anyway to use relative paths for the FIND_XXX commands. A simple additions to the docs "Don't use relative paths..." would suffice.

(0022025) David Cole (manager) 2010-08-31 15:29	We will not be addressing this for the upcoming CMake 2.8.3 release.

(0023831) Brad King (manager) 2010-12-08 17:48	Interestingly your proposed patch exactly reverses a hunk of this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a32cec9#patch10 [^] which was done for BeOS support. I don't know why.

(0023832) Brad King (manager) 2010-12-08 18:07	Patch applied: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=306427c0 [^]

Issue History
Date Modified	Username	Field	Change
2010-02-26 05:56	Marcel Loose	New Issue
2010-02-26 08:35	Marcel Loose	File Added: realpath.patch
2010-02-26 08:42	Marcel Loose	Note Added: 0019641
2010-08-31 15:29	David Cole	Note Added: 0022025
2010-11-10 11:48	David Cole	Assigned To	=> Brad King
2010-11-10 11:48	David Cole	Status	new => assigned
2010-11-10 11:48	David Cole	Target Version	=> CMake 2.8.4
2010-12-08 17:48	Brad King	Note Added: 0023831
2010-12-08 18:07	Brad King	Note Added: 0023832
2010-12-08 18:08	Brad King	Status	assigned => closed
2010-12-08 18:08	Brad King	Resolution	open => fixed
2010-12-09 10:40	Brad King	Relationship added	has duplicate 0011541
2011-01-12 07:20	David Cole	Fixed in Version	=> CMake 2.8.4