I've discovered an odd an seemingly incorrect behavior of
get_filename_component(REALPATH)... apparently there are some conditions
when it can take a canonical path and turn it *back into a symlink*.
To reproduce:
$ ls -l
lrwxrwxrwx. 1 matthew matthew 10 Mar 13 20:17 build -> real-build
drwxrwxr-x. 3 matthew matthew 4096 Mar 13 20:32 real-build
drwxrwxr-x. 2 matthew matthew 4096 Mar 13 20:30 real-src
lrwxrwxrwx. 1 matthew matthew 8 Mar 13 20:17 src -> real-src
$ cat src/CMakeLists.txt
cmake_minimum_required(VERSION 2.8.10)
project(Foo)
get_filename_component(rbd "${CMAKE_BINARY_DIR}" REALPATH)
get_filename_component(rp "${r_b_d}/foo.h" REALPATH)
message(STATUS "Expected value of real_path : '${r_b_d}/foo.h'")
message(STATUS "Actual value of real_path : '${rp}'")
$ ROOT=$PWD
$ cd build
$ cmake $ROOT/src
-- Expected value of real_path : '/path/to/real-build/foo.h'
-- Actual value of real_path : '/path/to/build/foo.h'
-- Configuring done
-- Generating done
-- Build files have been written to: /path/to/build
I'm almost afraid to think how REALPATH is implemented that it has this
ability that normally shouldn't be possible. I also can't imagine how it
is correct, since the result of REALPATH contains a resolvable symbolic
link, in complete contradiction to the documentation.
(Notes: This only happens if foo.h does not exist. 'readlink -f' gives
the expected result for the same input.)
Thoughts? Time to file a bug?
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
