Review Request 117836: Now IDM (Includes/Defines manager) provides all types of includes/defines, not just user-specified. (kdevelop)

[Olivier Jean de Gaalon]

> On May 2, 2014, 10:15 a.m., Milian Wolff wrote:
> > languages/plugins/custom-definesandincludes/definesandincludesmanager.cpp, line 108
> > <https://git.reviewboard.kde.org/r/117836/diff/3/?file=270617#file270617line108>
> >
> >     this way, project-specific defines will overwrite user-defined ones, is that correct?
> 
> Sergey Kalinichev wrote:
>     Yes, but only if an user set defines with the same name as build system.
>     
>     >I just wonder about the importance of ProjectSpecific vs. UserDefined - what should take preference
>     
>     IMO it should stay that way, as project specific i/d have higher priority (because they come from build manager and obviously have valid values) and it does't make sence to overwrite it here as we can do it through project manager.
>        Anyhow in futher commits (related to the GUI impovements) I'll add a check, that verify if given include/define already exist.

If this is how it's setup, I have no way to have KDevelop override the buildsystem for my own nefarious purposes, and I'd instead have to hack the buildsystem to workaround KDevelop. This is not desirable, since KDevelop is aware of the buildsystem, but not vice-versa.

There are reasonable use cases for overriding the buildsystem in the IDE, and this is the correct place to do it.

On the other hand, I see no use case for the buildsystem to override a value I specifically set in KDevelop that won't be seen by anyone else but KDevelop.


- Olivier Jean de


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117836/#review57107
-----------------------------------------------------------


On May 1, 2014, 11:22 a.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117836/
> -----------------------------------------------------------
> 
> (Updated May 1, 2014, 11:22 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
>   Currently to retrieve i/d we use IBuildSystemManager, that's imo very strange, as I don't see any reason why e.g. builder() method and includes() should be in one interface? Language plugins obviously don't use the former... 
>   Also not all project manager use i/d functionality (e.g. Custom build system doesn't).
>   Finally, with that path applied it becomes simpler to retrieve i/d as now all information is accessible from one place.
> 
> 
> Diffs
> -----
> 
>   languages/cpp/includepathcomputer.cpp c3bc05a 
>   languages/plugins/custom-definesandincludes/definesandincludesmanager.h bd560eb 
>   languages/plugins/custom-definesandincludes/definesandincludesmanager.cpp d1723d3 
>   languages/plugins/custom-definesandincludes/kdevdefinesandincludesmanager.desktop.cmake 65b933f 
>   projectmanagers/custom-buildsystem/custombuildsystemplugin.h 0798602 
>   projectmanagers/custom-buildsystem/custombuildsystemplugin.cpp db194a4 
>   projectmanagers/custommake/custommakemanager.h 6946e62 
>   projectmanagers/custommake/custommakemanager.cpp 346c8cd 
> 
> Diff: https://git.reviewboard.kde.org/r/117836/diff/
> 
> 
> Testing
> -------
> 
> Everything language/project related still passes (except cmakeprojectvisitortest, but it doesn't work for me either way.)
> 
> 
> Thanks,
> 
> Sergey Kalinichev
> 
>

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