Review Request 128272: support -iframework and -F header search path options

Tue Jun 28 10:58:40 UTC 2016

> On June 27, 2016, 8:59 a.m., Milian Wolff wrote:
> > projectmanagers/custommake/makefileresolver/makefileresolver.cpp, line 258
> > <https://git.reviewboard.kde.org/r/128272/diff/10/?file=469925#file469925line258>
> >
> >     also put this into a function or lambda and share code
> 
> René J.V. Bertin wrote:
>     lambdas for sharing code? Don't they usually have the opposite effect?
> 
> Milian Wolff wrote:
>     what? no! I call FUD!
> 
> René J.V. Bertin wrote:
>     I know this isn't really the place, but I've mostly seen lambda expressions used as an alternative to writing a dedicated function to pass as a function pointer. In Lisp and Python, I admit, so I'm bound to overlook something.
>     Of course you can use a function pointer in a refactoring effort to share code, where the function pointer provides some specific functionality called from a common, sharable workload. But if you can provide that functionality via a lambda because you don't need to call it from elsewhere you can just as well skip the use of a function pointer.

René, seriously, could you stop debating *every* single remark in a review request, and just fix those issue as we kindly ask you to do it? You don't even need to reply, just *do* it. Remember, all of the core developers in KDevelop are software developers with more than 10 years of experience in both professional & spare-time hacking, all of them maintaining large-scale code bases over a significant amount of time.

We're not just talking trash, there's some evidence we know what we're talking about.

Sorry for the rant, but this is not exclusive to this particular comment -- the debating from your side spreads all over reviewboard.kde.org & other communication channels. Please give us a hand in reducing the communication overhead (just compare the amount of discussions going on in your review requests against those of others, it literally costs us time!)

Thanks!

- Kevin

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

On June 27, 2016, 9:28 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128272/
> -----------------------------------------------------------
> 
> (Updated June 27, 2016, 9:28 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
> This is a draft implementation for parser support of the `-iframework dir` and `-F dir` compiler arguments. On OS X these are the framework equivalents of `-isystem` and `-I` respectively, telling the compiler and/or linker where to find framework bundles.
> 
> I started out making the new code available on OS X only but that introduces a lot of #ifdefs for probably little benefit. On the contrary, clang supports the arguments on Linux too, presumably because clang is a functional cross-compiler that can generate Darwin Mach-O object files on Linux too.
> 
> For the 1st approach I propose to parse the framework directories, adding the effective header directories of the individual frameworks as if they were added explicitly. The framework directories are also added to a new list in the result structure. I presume that this is a prerequisite for adding them to the (lib)clang arguments of the clang parser.
> 
> 
> Diffs
> -----
> 
>   languages/clang/clangparsejob.cpp 8375eb5 
>   languages/clang/duchain/clangparsingenvironment.h c689132 
>   languages/clang/duchain/clangparsingenvironment.cpp b515037 
>   languages/clang/duchain/parsesession.cpp aae0661 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.h 7a5184f 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.cpp 24e532a 
>   languages/plugins/custom-definesandincludes/definesandincludesmanager.h 6d0d210 
>   languages/plugins/custom-definesandincludes/definesandincludesmanager.cpp ebceb4d 
>   languages/plugins/custom-definesandincludes/idefinesandincludesmanager.h 5da71f2 
>   projectmanagers/cmake/cmakeimportjsonjob.cpp f064647 
>   projectmanagers/cmake/cmakemanager.h 3096b7d 
>   projectmanagers/cmake/cmakemanager.cpp 5c15e2f 
>   projectmanagers/cmake/cmakeprojectdata.h 60e8773 
>   projectmanagers/custom-buildsystem/custombuildsystemplugin.h 372b283 
>   projectmanagers/custom-buildsystem/custombuildsystemplugin.cpp b04647e 
>   projectmanagers/custommake/custommakemanager.h 33c2997 
>   projectmanagers/custommake/custommakemanager.cpp e2ce943 
>   projectmanagers/custommake/makefileresolver/makefileresolver.h debe977 
>   projectmanagers/custommake/makefileresolver/makefileresolver.cpp 97973d4 
>   projectmanagers/custommake/makefileresolver/tests/test_custommake.h 3ad0f36 
>   projectmanagers/custommake/makefileresolver/tests/test_custommake.cpp 368e83e 
>   projectmanagers/qmake/qmakemanager.h e5e3266 
>   projectmanagers/qmake/qmakemanager.cpp 123b474 
> 
> Diff: https://git.reviewboard.kde.org/r/128272/diff/
> 
> 
> Testing
> -------
> 
> the unittest works as expected on OS X.
> 
> 20160625: the patch works as expected on OS X. The `-iframework /opt/local/libexec/qt5/Library/Frameworks` argument added by cmake to each compiler invocation is detected and put to use; Qt header files are found in the frameworks without a wrapper Qt5 header directory (`/opt/local/include/qt5`) added to the header search path. Header files from the system SDKs are found too
> 
> 
> File Attachments
> ----------------
> 
> the real companion patch for kdevplatform
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/06/22/67189f62-ec2c-4797-a315-cafc44fbbb6d__patch-support-kdevp-frameworks.diff
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160628/4c3c493a/attachment-0001.html>