[cmake-developers] [CMake 0015743]: get_filename_component turns real path to ABSOLUTE path

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15743 
====================================================================== 
Reported By:                Andreas Schuh
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15743
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-09-15 11:15 EDT
Last Modified:              2015-09-15 11:15 EDT
====================================================================== 
Summary:                    get_filename_component turns real path to ABSOLUTE
path
Description: 
I encountered a very strange behaviour of the get_filename_component using the
ABSOLUTE subcommand. The given input path was before turned into a real path
with symbolic links resolved using the REALPATH subcommand. Calling
get_filename_component with ABSOLUTE on this real path I would have expected an
unchanged path. Instead, ABSOLUTE returns a path with symbolic links again! Note
that both the source and build directory are located in different symlinked
directory paths.

Looking at the C++ code of the get_filename_component command revealed some
strange call to SystemTools::CheckTranslationPath in
SystemTools::CollapseFullPath which implements the ABSOLUTE subcommand. There is
also a commented line beforehand with a comment expecting to break something by
doing so... the call to SystemTools::AddTranslationPath.

The issue affects also previous releases (tried 3.2.2 and 2.8.12.2).

IMHO I find it extremely strange that get_filename_component needs such
translation table (without having digged deeper to fully understand its
purpose). Cleaning a path or splitting it into parts should be a purely string
based operation without actual file system information.

Steps to Reproduce: 
1. Create directory hierarchy with symlinks similar to my scenario:

  Real source directory:
    /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue

  Real build directory:
    /vol/biomedic/users/as12312/build/merapi/cmake-get_filename_component-issue

  Symbolic links:
    /homes/as12312/Code -> /vol/medic01/users/as12312/Code
    /homes/as12312/opt -> /vol/biomedic/users/as12312

2. Copy attached CMakeLists.txt to the source directory
3. Change into the symlinked build directory and use the symbolic link to the
source directory as argument to CMake

  cd /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue
  cmake /homes/as12321/Code/CMakeGetFileNameComponentIssue

The output is the following:

CMAKE_SOURCE_DIR:
	REALPATH = /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue
	ABSOLUTE = /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue
CMAKE_BINARY_DIR:
	REALPATH =
/vol/biomedic/users/as12312/build/merapi/cmake-get_filename_component-issue
	ABSOLUTE = /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue
-- Configuring done
-- Generating done
-- Build files have been written to:
/homes/as12312/opt/build/merapi/cmake-get_filename_component-issue

Note that the ABSOLUTE return value of get_filename_component of the real input
path contains symbolic links again!
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-09-15 11:15 Andreas Schuh  New Issue                                    
2015-09-15 11:15 Andreas Schuh  File Added: CMakeLists.txt                    
======================================================================