[cmake-developers] bizarre g_f_c(REALPATH) bug; works backwards(?!)

[Matthew Woehlke]

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