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

Aleix Pol Gonzalez aleixpol at kde.org
Mon Apr 28 17:33:53 UTC 2014


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



projectmanagers/cmake/tests/cmakemanagertest.cpp
<https://git.reviewboard.kde.org/r/117836/#comment39638>

    What????
    
    IBSM::defines still needs to return properly, so does ::includes.


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.

- Aleix Pol Gonzalez


On April 28, 2014, 11:04 a.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117836/
> -----------------------------------------------------------
> 
> (Updated April 28, 2014, 11:04 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.
> 
>   There is one issue though: In CMakeManager::projectData() there is the assert with QThread::currentThread() == project->thread(), that I commented out. Currently it works without assertion, as processGeneratorExpression directly accesses m_projectsData, but with this path it becomes impossible to do that (only through friend class or something...).
>   So, is it ok to comment it out?
> 
> 
> 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/20140428/cee1a95f/attachment.html>


More information about the KDevelop-devel mailing list