Review Request 121757: Use target environment whenever available

Nicolai Hähnle nhaehnle at gmail.com
Tue Dec 30 22:46:47 UTC 2014


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


I'm not familiar with this code, but the issue you want to address seems related to this review request: https://git.reviewboard.kde.org/r/121649/ Hopefully, a correct way for dealing with the issue of parsing header files can be found!

- Nicolai Hähnle


On Dez. 30, 2014, 4:02 nachm., Olivier Jean de Gaalon wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121757/
> -----------------------------------------------------------
> 
> (Updated Dez. 30, 2014, 4:02 nachm.)
> 
> 
> 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/f1310a93/attachment.html>


More information about the KDevelop-devel mailing list