<div dir="ltr">Hi,<br><br>I discovered a very unexpected -S behaviour and I'd like to know whether it's a bug or a feature.<br><br>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.<br><br>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. <br><br>Example:<br><br>ls ~/cmake/tu/to/rial<br>~/cmake/tu/to/rial/CMakeLists.txt<br>~/cmake/tu/to/rial/tutorial.cxx<br><br>ln -s ~/cmake/tu ~/tutosym<br>cd ~/tutosym<br><br>cmake -B ~/build -S ~/cmake/tu/to/rial<br><br>grep -r to/rial ~/build/<br>build/Makefile:CMAKE_SOURCE_DIR = ~/tutosym/to/rial       #  <= made up by cmake<br>build/CMakeFiles/Makefile2:CMAKE_SOURCE_DIR = ~/tutosym/to/rial<br>build/CMakeCache.txt:Tutorial_SOURCE_DIR:STATIC=~/tutosym/to/rial<br>etc.<br><br>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.<br><br>Example:<br><br>cd ~/cmake/<br>cmake -B ~/build -S ~/tutosym/to/rial<br><br>grep -r to/rial ~/build/<br><exact same as above><br><br>Is this behaviour intentional?<div><br>Reproduced with cmake 3.14.3.<div>-GNinja makes no difference.<br></div></div></div>