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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Marc Herbert
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
Reply | Threaded
Open this post in threaded view
|

Re: cmake rewrites part of -S argument depending on the current directory!

CMake mailing list
On 5/30/19 3:22 AM, Marc Herbert wrote:
> 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.

See this issue:

  https://gitlab.kitware.com/cmake/cmake/issues/16228

-Brad
--

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
Reply | Threaded
Open this post in threaded view
|

Re: cmake rewrites part of -S argument depending on the current directory!

Marc Herbert
Thanks Brad for the reference, really appreciated. Some of 16228 seems relevant. Other parts unfortunately not because 16228:
- tries to deal with all the crazy ways users can use symbolic links, including relative paths and relative links,
- tries to deal with all the ways users can invoke cmake,
- naturally cares about backward compatibility,
- goes deep into the implementation details,
- refers to other issues with even more implementation details.

So I'm admittedly getting lost in all the details and combinatorial explosion. Because 16228 looks like a bug I suspect the behaviour I described is also considered a bug but I'm not even sure?

I believe the example I gave is one of the simplest and safest use cases of symbolic links that : passing both -B and -S, no relative path, no relative link. For such a "most explicit" use case, will future cmake versions be unaffected by the current directory?

-B is a brand new option so there's only so much backward compatibility it has to care about, right?

Long story short I think this admittedly complex topic could use some high level documentation or - if the symlink situation is hopelessly complicated and everything fails - at least a big "AVOID SYMLINKS [FOR NOW]" warning somewhere in the documentation. Fair enough? Sorry if I missed that.

Thanks!

Marc


Le jeu. 30 mai 2019 à 07:15, Brad King <[hidden email]> a écrit :
On 5/30/19 3:22 AM, Marc Herbert wrote:
> 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.

See this issue:

  https://gitlab.kitware.com/cmake/cmake/issues/16228

-Brad

--

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
Reply | Threaded
Open this post in threaded view
|

Re: cmake rewrites part of -S argument depending on the current directory!

CMake mailing list
On 5/30/19 1:25 PM, Marc Herbert wrote:
> I suspect the behaviour I described is also considered a bug

Yes, it is a bug and is related to 16228.  The problem is that
there is a poor implementation of support for the use case
described in that issue, and the details of that implementation
leak out in other use cases.

Ben (in Cc) has a plan to resolve the problem but hasn't had
time to implement it yet.

-Brad
--

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