MantisBT - CMake
View Issue Details
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.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-16 00:38Stewart SmithNew Issue
2012-05-16 08:49Brad KingNote Added: 0029480
2012-05-16 08:49Brad KingStatusnew => resolved
2012-05-16 08:49Brad KingResolutionopen => won't fix
2012-05-17 03:36Stewart SmithNote Added: 0029493
2012-05-17 03:36Stewart SmithStatusresolved => feedback
2012-05-17 03:36Stewart SmithResolutionwon't fix => reopened
2012-05-17 07:57Brad KingNote Added: 0029494
2012-05-17 07:57Brad KingStatusfeedback => resolved
2012-05-17 07:57Brad KingResolutionreopened => won't fix
2012-05-17 08:46Stewart SmithNote Added: 0029495
2012-05-17 08:46Stewart SmithStatusresolved => feedback
2012-05-17 08:46Stewart SmithResolutionwon't fix => reopened
2012-05-17 08:59Brad KingNote Added: 0029496
2012-05-17 08:59Brad KingStatusfeedback => resolved
2012-05-17 08:59Brad KingResolutionreopened => won't fix
2012-10-01 13:23David ColeNote Added: 0031131
2012-10-01 13:23David ColeStatusresolved => closed

Notes
(0029480)
Brad King   
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   
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   
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   
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   
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   
2012-10-01 13:23   
Closing resolved issues that have not been updated in more than 4 months.