View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013257 | CMake | CMake | public | 2012-05-30 04:45 | 2013-01-09 10:57 | ||||
Reporter | Andreas Mohr | ||||||||
Assigned To | David Cole | ||||||||
Priority | normal | Severity | feature | Reproducibility | have not tried | ||||
Status | closed | Resolution | no change required | ||||||
Platform | x86 | OS | Linux | OS Version | RHEL5 | ||||
Product Version | CMake 2.8.8 | ||||||||
Target Version | Fixed in Version | CMake 2.8.10 | |||||||
Summary | 0013257: On-the-fly switching of CMake generators (flexible build tree recreation) results in broken partial reconfiguration | ||||||||
Description | To investigate configuration issues with a certain CMakeCache.txt setup, it would be *very helpful* to be able to create a new *pristine* build directory, copy the old sufficiently complex (too many settings to try to figure out individually) CMakeCache.txt there, adapt CMakeCache.txt's build directory entries to the new name of the sibling directory, and then run e.g. "cmake -DCMAKE_GENERATOR="Unix Makefiles" ." (WITHIN BUILD TREE) to let CMake *re*create an entirely fresh build tree yet with a *slightly* different configuration (in this case, switching the generator). Well... this actually works. Going from a previous Ninja-based build tree, the new build directory now actually gets a full Makefile-based hierarchy created. Except... it falls flat on its face, since CMAKE_MAKE_PROGRAM and CMAKE_BUILD_TOOL remain set to the old Ninja-based arguments and don't get overridden to a Makefile-side setting when reconfiguring CMAKE_GENERATOR. Bad doggy, no cake today. Manually correcting the two cache variables to contain correct Makefile-side entries does seem to make everything work as expected (successfully test-builds an entire library target using make). Summary: - we want to play some thoroughly helpful tricks - it *almost* works - yet some stupid remaining non-overridden parts prevent it from working - Majorly annoying bug?? Hell yeah, we've got a winner... The question would be how to change CMake to handle it properly. Possibly required steps: 1. add detection to correctly realize that there's a change in CMAKE_GENERATOR setting (from old to new) 2. override CMAKE_MAKE_PROGRAM (or simply kill cache variable, to then simply automatically have it configured later) 3. dito with CMAKE_BUILD_TOOL I chose to initially indicate Severity "major" since it breaks an IMHO very useful feature. Thanks! | ||||||||
Steps To Reproduce | See initial paragraph in text above. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0029896) Peter Kuemmel (developer) 2012-07-03 09:28 |
It's not a bug, it's a feature request. |
(0030268) David Cole (manager) 2012-08-11 11:16 |
If you want to switch the generator, please use separate build trees. The problem (in general) is that we have no idea WHAT the cache values present in an existing CMakeCache.txt of a build tree DEPEND ON. Some may depend on compiler flags, some on paths, some on the generator used, some on complex logic in the CMakeLists file, some on ... you get the idea. So: unless we introduce the concept of dependencies at the variable level, we have no idea what a "change of generator" means in terms of cache results. Yes, when using Unix Makefiles and switching to ninja, you should be able to use all the same compiler flags, and have all the try_compile results be valid... But the bottom line is there is simply no way to verify it without a significant effort that tracks what values go into producing a cache value and tracking the dependencies of those cache values on all of those inputs that might affect its outcome. I am of the opinion that the work required to get this "right" would far outweigh any time-savings benefit here. Please use multiple build trees for multiple generators. |
(0032043) Robert Maynard (manager) 2013-01-09 10:57 |
Closing resolved issues that have not been updated in more than 4 months. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2012-05-30 04:45 | Andreas Mohr | New Issue | |
2012-07-03 09:27 | Peter Kuemmel | Severity | major => feature |
2012-07-03 09:28 | Peter Kuemmel | Note Added: 0029896 | |
2012-08-11 11:10 | David Cole | Assigned To | => David Cole |
2012-08-11 11:10 | David Cole | Status | new => assigned |
2012-08-11 11:16 | David Cole | Note Added: 0030268 | |
2012-08-11 11:16 | David Cole | Status | assigned => resolved |
2012-08-11 11:16 | David Cole | Fixed in Version | => CMake 2.8.10 |
2012-08-11 11:16 | David Cole | Resolution | open => no change required |
2013-01-09 10:57 | Robert Maynard | Note Added: 0032043 | |
2013-01-09 10:57 | Robert Maynard | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |