[CMake] cmake rewrites part of -S argument depending on the current directory!

Marc Herbert marc.herbert at gmail.com
Thu May 30 03:22:28 EDT 2019


Hi,

I discovered a very unexpected -S behaviour and I'd like to know whether
it's a bug or a feature.

IF the current directory is a parent of the -S argument AND one component
of the current directory is a symbolic link THEN the leading part of the -S
argument is overridden using that symbolic link.

I really didn't expect the current directory to be able to make any
difference to -S, especially not when passing absolute paths to both -B and
-S. I haven't found anything about that in the documentation.

Example:

ls ~/cmake/tu/to/rial
~/cmake/tu/to/rial/CMakeLists.txt
~/cmake/tu/to/rial/tutorial.cxx

ln -s ~/cmake/tu ~/tutosym
cd ~/tutosym

cmake -B ~/build -S ~/cmake/tu/to/rial

grep -r to/rial ~/build/
build/Makefile:CMAKE_SOURCE_DIR = ~/tutosym/to/rial       #  <= made up by
cmake
build/CMakeFiles/Makefile2:CMAKE_SOURCE_DIR = ~/tutosym/to/rial
build/CMakeCache.txt:Tutorial_SOURCE_DIR:STATIC=~/tutosym/to/rial
etc.

Funny enough the converse isn't true: if the current directory is a "real"
parent of the -S argument that has a symbolic link, then the -S argument is
respected. It's like symbolic links have a "higher priority" of some sort.

Example:

cd ~/cmake/
cmake -B ~/build -S ~/tutosym/to/rial

grep -r to/rial ~/build/
<exact same as above>

Is this behaviour intentional?

Reproduced with cmake 3.14.3.
-GNinja makes no difference.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190530/7163f528/attachment.html>


More information about the CMake mailing list