The following issue has been SUBMITTED. ====================================================================== http://www.itk.org/Bug/view.php?id=13257 ====================================================================== Reported By: Andreas Mohr Assigned To: ====================================================================== Project: CMake Issue ID: 13257 Category: CMake Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2012-05-30 04:45 EDT Last Modified: 2012-05-30 04:45 EDT ====================================================================== Summary: 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. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2012-05-30 04:45 Andreas Mohr New Issue ====================================================================== -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
