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

[René J.V. Bertin]

> On June 22, 2016, 11:57 a.m., Milian Wolff wrote:
> > projectmanagers/custommake/makefileresolver/makefileresolver.cpp, line 700
> > <https://git.reviewboard.kde.org/r/128272/diff/3/?file=469714#file469714line700>
> >
> >     please introduce a helper function and call that instead of allocating a temporary buffer to loop over.
> 
> René J.V. Bertin wrote:
>     You mean you want to duplicate actual payload, the code I moved inside the foreach loop?
>     
>     I propose to wait and see if we can get a functional support for -iframework and -F into the actual parser. When that happens there should be no more need to construct our own list of the include directories under a framework directory.

On second thought this whole feature was without interest. Code depending on -iframework or -F will prepend its include directives with the framework name (e.g. `#include <QtGui/QtGui>`). Adding -isystem or -I options to point the compiler to the frameworks' Headers directories isn't going to help that code (i.e. `QtGui.frameworks/Headers/GtGui/QtGui` doesn't exist).

Thus the temporary buffer (or helper function) becomes unnecessary.


- René J.V.


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


On June 22, 2016, 8:50 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 22, 2016, 8:50 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
> -----
> 
>   projectmanagers/custommake/makefileresolver/makefileresolver.h 22f9dba 
>   projectmanagers/custommake/makefileresolver/makefileresolver.cpp ab069bb 
>   projectmanagers/custommake/makefileresolver/tests/test_custommake.h 3ad0f36 
>   projectmanagers/custommake/makefileresolver/tests/test_custommake.cpp 368e83e 
> 
> Diff: https://git.reviewboard.kde.org/r/128272/diff/
> 
> 
> Testing
> -------
> 
> the unittest works as expected on OS X.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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