Review Request: Store CMake build system settings per build directory rather than globally (TODO in cmakepreferences.cpp)

[Andreas Pakulat]

> On July 1, 2012, 10:34 p.m., Aleix Pol Gonzalez wrote:
> > Hi
> > In general I like the idea of the patch. Improving consistency between build directories configurations is something good.
> > 
> > On the other hand, first if you could update your version to the current master it would be great, the patch appears malformed here. Also I'd like you to try what happens if you modify the cache outside of KDevelop and reconfigure.
> > 
> > Here we should figure out which arguments to use, no? Your solution would go back to the first values for the build directory, but maybe it should synchronize to the last value found?
> 
> Ivan Shapovalov wrote:
>     Ok - except extra arguments; there is no simple way to tell if the corresponding cache entries have been modified or even if the extra arguments were taken into account at all.
> 
> Andreas Pakulat wrote:
>     We cannot figure out which of the cache-entries where modified outside or how their values got there initially. So we don't know which of the parameters that are set to be used for calling cmake influences which cmake variables. Hence it does not make sense in my opinion to require to have manually-edited entries in the cache persist across a  re-configure run. We just need to make it clear to the user that a re-configure means the same as running cmake with all the -D-Arguments he provided and that is clearly visible in the output window IIRC.
> 
> Ivan Shapovalov wrote:
>     That's just what has been done. Three specific options (build type, install prefix and cmake executable path) are re-loaded from the cache upon project load and configure; the rest (extra arguments) aren't touched in any way.
>     
>     There is another question regarding these settings, but I'll post it to the mailing list.

Actually, changing the build-type should not be supported, since cmake does not really support doing it in the cache either. Changing the build-type is known to require a complete cleanup of the build directory since cmake has no dependency tracking for compiler arguments and hence your files may end up with a complete mix of compiler arguments and even be completely incompatible to one another on some platforms. Its also not really something that people change while working on a project IMO, its something they set for a given directory once.

I think the other two are ok, but I'm not 100% sure, might be worth a check with the cmake list to verify they're supported to be changed in an already configured and populated build tree.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105308/#review15297
-----------------------------------------------------------


On July 2, 2012, 12:13 a.m., Ivan Shapovalov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105308/
> -----------------------------------------------------------
> 
> (Updated July 2, 2012, 12:13 a.m.)
> 
> 
> Review request for KDevelop and Aleix Pol Gonzalez.
> 
> 
> Description
> -------
> 
> This addresses the TODO at the beginning of cmakepreferences.cpp, making
> CMake build system settings saved in the project configuration file
> separately for each configured build directory.
> This is now done by using sub-groups per each configured build directory (as suggested by Andreas).
> Specifically, 5 places have been changed:
> * cmakeconfig.kcfg: dropped.
> * cmakeutils.{h,cpp}: functions changed to use multiple groups.
> * cmakepreferences.{h,cpp}: functions changed to use primitives from cmakeutils.{h,cpp} + commented out
> the save() call on build directory creation since it is somewhat annoying.
> * cmakejob.cpp: cmakeArguments() had been changed to make it use
> temporary variables instead of calling each fetch function twice.
> * cmakemanager.cpp: on project load there is attempt to migrate the configuration file to new format.
> 
> URLs are saved to via KUrl::url().
> 
> 
> Diffs
> -----
> 
>   projectbuilders/cmakebuilder/cmakejob.cpp af05577 
>   projectmanagers/cmake/CMakeLists.txt dc013f4 
>   projectmanagers/cmake/cmakeconfig.kcfg 5ca623e 
>   projectmanagers/cmake/cmakeconfig.kcfgc d580702 
>   projectmanagers/cmake/cmakemanager.cpp ad496e7 
>   projectmanagers/cmake/cmakeutils.h 5586d4d 
>   projectmanagers/cmake/cmakeutils.cpp 3c9b736 
>   projectmanagers/cmake/settings/cmakepreferences.h 4195948 
>   projectmanagers/cmake/settings/cmakepreferences.cpp 5be668b 
> 
> Diff: http://git.reviewboard.kde.org/r/105308/diff/
> 
> 
> Testing
> -------
> 
> Used two build directories on a project, one configured to build with MinGW via -DCMAKE_TOOLCHAIN_FILE.
> Ensured the settings are saved and applied correctly across build directory switch and KDevelop multiple restart.
> Existing projects' configurations are picked up correctly.
> 
> All unit-tests are also passed.
> 
> 
> Thanks,
> 
> Ivan Shapovalov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120702/bd7e0799/attachment.html>