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

Andreas Pakulat apaku at gmx.de
Mon Jul 2 07:17:57 UTC 2012



> 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.

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.


- 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/805d5345/attachment.html>


More information about the KDevelop-devel mailing list