Review Request 121757: Use target environment whenever available

[Olivier Jean de Gaalon]

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

Review request for KDevelop, Kevin Funk and Milian Wolff.


Repository: kdev-clang


Description
-------

Note: this currently does nothing useful, since none of the managers actually create target items.  

The problem I'm running into right now is that kdev-clang will get only the base system includes for all headers in the (cmake) project. This is correct from the build manager's perspective: include paths are for targets. This is completely broken for kdev-clang of course.  
If we accept that reasoning, kdev-clang needs to prefer the target environment when it becomes available, so that the headers are rebuilt with the correct includes+defines when requested from the target. That's what this patch purports to do (in theory).  

This could maybe instead use an enum to prefer project over no-project and target over all.  

Objections:  
1. If I create a new header in the project, I still won't get project includes
2. This is really just a hack over the hack of building ASTs for non-targets in the first place
  2.1 but obviously any solution to said hack needs to allow auto-force-duchaining of non-targets for orphan files, because we like that feature

Any other thoughts or ideas?


Diffs
-----

  clangparsejob.cpp 297b836 
  duchain/clangparsingenvironment.h 7bb8111 
  duchain/clangparsingenvironment.cpp 1decc14 
  duchain/clangparsingenvironmentfile.h 953ee94 
  duchain/clangparsingenvironmentfile.cpp b3d0563 
  tests/test_duchain.cpp 7db9fea 

Diff: https://git.reviewboard.kde.org/r/121757/diff/


Testing
-------

Tests fail in the same manner as before


Thanks,

Olivier Jean de Gaalon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20141230/2ec1fd7b/attachment.html>