View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013226CMakeCMakepublic2012-05-16 00:382012-10-01 13:23
ReporterStewart Smith 
Assigned To 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
Platformany (that supports symlinks)OSOS Version
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0013226: CMake doesn't call realpath(), causing it to get confused if built through symlink
DescriptionIf you have something like this:

product (the directory)
and product-1.0 being a symlink to product
and at a later date, product-1.1 being a symlink to product

and you once built through "cd product-1.0; make" and in future "cd product-1.1; make", then it's possible for an *in source tree* build to have the following condition met when it shouldn't be:

IF(NOT ${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})

As Cmake caches things, repeated builds get the old 'product-1.0' in path in one of the variables and the new 'product-1.1' in the other.

If the code in the CMakeLists.txt does something like overwrite a file to launch things correctly for out-of-tree builds (as it does in the MySQL source code), then you get a fork-bomb instead of a test-suite.

If CMake called realpath(3) on source and binary dirs when it was setting up the variables initially, this problem would be avoided as the comparison would always be done with the physical paths, not with what symlinks were used at any particular time.
Steps To Reproducesee above.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0029480)
Brad King (manager)
2012-05-16 08:49

 Many use cases require the symlinks to be preserved. Some people build on network mounts that change name and use symlinks to keep the names the same.

You can perform the same in-source check using get_filename_component to expand the symlinks using its REALPATH option.

If you need further discussion please post to the mailing list for broader visibility.
(0029493)
Stewart Smith (reporter)
2012-05-17 03:36

 If CMake was consistent, then I'd see your point. It's not. It depends on which directory you 'cd' into to execute cmake.

In this case this is the series of events:
cd a/ && cmake . && make
cd ../
cd b/ && cmake . && make

where a and b are symlinks to a tree.
This will cause the cmake run in b to pick up the cached path for a, and probably explode. You'd likely get the same issues if you went to the tree itself rather than the symlink.

So this would really only provide people with a false sense of security with symlinks and mounts. As long as they *only* ever used the original path, they'd be fine. But if they used the new path... possibly everything goes boom.

I haven't tested, but I guess this would also be the case if you moved the build directory too. maybe something like:
mv a b
mkdir a
cd b/
cmake .
make

could also cause a problem? and, in fact, have the CMakeLists.txt in b/ overwrite things in (a now unrelated) a/ ?
(0029494)
Brad King (manager)
2012-05-17 07:57

 We do not intend to support multiple names/symlinks for the same tree or renames of the source or build trees. Once CMake has been run to generate a given build tree with a given source tree the paths must remain the same after that. They are not relocatable.
(0029495)
Stewart Smith (reporter)
2012-05-17 08:46

 Our build system runs cmake before every build, so are you saying that a 'make distclean' equivalent should be run instead of just re-running cmake followed by make on directory rename or using a different symlink to access the path?
(0029496)
Brad King (manager)
2012-05-17 08:59

 CMake's equivalent to "make distclean" is to use an out-of-source build so the source tree is never touched at all. Then you can just wipe out the build tree and create a new one elsewhere, or just use multiple build trees sharing one source tree. Please join the mailing list for further help:

  http://www.cmake.org/mailman/listinfo/cmake [^]

The issue tracker is not a good place for such discussion.
(0031131)
David Cole (manager)
2012-10-01 13:23

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-05-16 00:38 Stewart Smith New Issue
2012-05-16 08:49 Brad King Note Added: 0029480
2012-05-16 08:49 Brad King Status new => resolved
2012-05-16 08:49 Brad King Resolution open => won't fix
2012-05-17 03:36 Stewart Smith Note Added: 0029493
2012-05-17 03:36 Stewart Smith Status resolved => feedback
2012-05-17 03:36 Stewart Smith Resolution won't fix => reopened
2012-05-17 07:57 Brad King Note Added: 0029494
2012-05-17 07:57 Brad King Status feedback => resolved
2012-05-17 07:57 Brad King Resolution reopened => won't fix
2012-05-17 08:46 Stewart Smith Note Added: 0029495
2012-05-17 08:46 Stewart Smith Status resolved => feedback
2012-05-17 08:46 Stewart Smith Resolution won't fix => reopened
2012-05-17 08:59 Brad King Note Added: 0029496
2012-05-17 08:59 Brad King Status feedback => resolved
2012-05-17 08:59 Brad King Resolution reopened => won't fix
2012-10-01 13:23 David Cole Note Added: 0031131
2012-10-01 13:23 David Cole Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team