[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