View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013257CMakeCMakepublic2012-05-30 04:452013-01-09 10:57
ReporterAndreas Mohr 
Assigned ToDavid Cole 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionno change required 
Platformx86OSLinuxOS VersionRHEL5
Product VersionCMake 2.8.8 
Target VersionFixed in VersionCMake 2.8.10 
Summary0013257: On-the-fly switching of CMake generators (flexible build tree recreation) results in broken partial reconfiguration
DescriptionTo 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 ReproduceSee initial paragraph in text above.
TagsNo tags attached.
Attached Files

 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.

 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


Copyright © 2000 - 2018 MantisBT Team