View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015743CMakeCMakepublic2015-09-15 11:152016-06-10 14:31
ReporterAndreas Schuh 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
Platformx86_64OSUbuntuOS Version14.04
Product VersionCMake 3.3.1 
Target VersionFixed in Version 
Summary0015743: get_filename_component turns real path to ABSOLUTE path
DescriptionI 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 Reproduce1. 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!
TagsNo tags attached.
Attached Filestxt file icon CMakeLists.txt [^] (503 bytes) 2015-09-15 11:15 [Show Content]

 Relationships

  Notes
(0042838)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 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
2016-06-10 14:29 Kitware Robot Note Added: 0042838
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team