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