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

[René J.V. Bertin]

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

(Updated June 25, 2016, 1:41 p.m.)


Review request for KDE Software on Mac OS X and KDevelop.


Changes
-------

This is the first working prototype. After all the trivial-but-tedious changes it was almost an anticlimax to see it work.

I don't really understand but it turns out to be necessary to add the system framework paths explicitly (`/Library/Frameworks` and `/System/Library/Frameworks`, in that order). Clang searches there by default when used as a compiler, but apparently it does not when used for parsing. To avoid yet more duplicatin I've implemented that default path via a `ClangParsingEnvironment` ctor, but only on OS X.

System SDK header files are now found in the default locations, which isn't necessarily the absolutely correct place to search. For parsing it ought to do most of the time but support for the `-isysroot` argument will need to be considered as a future modification (= a priori as a separate patch after committing and testing the current patch in the wild).


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 (updated)
-----

  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/CMakeLists.txt 5a6c5b7 
  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 (updated)
-------

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/20160625/a5840cae/attachment.html>