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

[Sergey Kalinichev]

> On April 28, 2014, 9:33 p.m., Aleix Pol Gonzalez wrote:
> > projectmanagers/cmake/tests/cmakemanagertest.cpp, line 231
> > <https://git.reviewboard.kde.org/r/117836/diff/1/?file=268920#file268920line231>
> >
> >     What????
> >     
> >     IBSM::defines still needs to return properly, so does ::includes.

Sorry, I don't follow... Why/how it can return something if I've removed those methods from IBSM interface?


On April 28, 2014, 9:33 p.m., Sergey Kalinichev wrote:
> > Personally, I think that IDefinesAndIncludesManager is introducing complexity in the wrong places.
> > 
> > CMakeManager needs to offer what cmake suggests. If you have different needs, then put something on top, but so far I don't like where this is going.

>CMakeManager needs to offer what cmake suggests.

And it does, only through one indirection layer: IDefinesAndIncludesManager.

>If you have different needs, then put something on top

You mean IADM should query IBSM for i/d? But in that case there'll be 2 differnt sources of i/d, returning almost the same data, that's imo is not very good... 

Also I don't quite get what is wrong with the approach that I suggest?


- Sergey


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


On April 29, 2014, 3:21 p.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117836/
> -----------------------------------------------------------
> 
> (Updated April 29, 2014, 3:21 p.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 74fcc16 
>   languages/plugins/custom-definesandincludes/definesandincludesmanager.h bd560eb 
>   languages/plugins/custom-definesandincludes/definesandincludesmanager.cpp d1723d3 
>   languages/plugins/custom-definesandincludes/kdevdefinesandincludesmanager.desktop.cmake 65b933f 
>   projectmanagers/cmake/cmakemanager.h 19fc0c1 
>   projectmanagers/cmake/cmakemanager.cpp 99e9e21 
>   projectmanagers/cmake/tests/cmakemanagertest.cpp 4e83175 
>   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/20140429/7b5e6353/attachment.html>