View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013226 | CMake | CMake | public | 2012-05-16 00:38 | 2012-10-01 13:23 | ||||
Reporter | Stewart Smith | ||||||||
Assigned To | |||||||||
Priority | high | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | won't fix | ||||||
Platform | any (that supports symlinks) | OS | OS Version | ||||||
Product Version | CMake 2.8.7 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0013226: CMake doesn't call realpath(), causing it to get confused if built through symlink | ||||||||
Description | If 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 Reproduce | see above. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |