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.
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
