Review Request 115057: Prefer non-empty when computing include paths.

Ben Wagner bungeman at gmail.com
Fri Jan 17 10:54:09 UTC 2014


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

(Updated Jan. 17, 2014, 10:54 a.m.)


Status
------

This change has been marked as submitted.


Review request for KDevelop.


Repository: kdevelop


Description
-------

In some CMake projects a file may be listed as a source file in a 'real' target but also listed as a source to a 'custom' target. Custom targets don't handle includes, so depending on the order of evaluation when computing include paths, one may or may not get any includes.

This change causes include path computation to prefer file items in targets over those not in targets (as was the case before) and also prefer file items in targets with includes over those without includes.

This change grew out of my frustration with the randomness with which file item was picked to represent the file. I have a project in which several files exist in a 'real' target which has the correct includes, but the same files also end up in a 'custom' target which, of course, doesn't have any includes. In general if a file exists in multiple targets, it makes sense to prefer one of the ones with some includes over targets with no includes. This is the best improvement I could think of with relation to this which doesn't use some union of includes or add some user option to force which file item should be used.


Diffs
-----

  languages/cpp/includepathcomputer.cpp a013bc9 

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


Testing
-------

Built. Ran. Fixed my problem.


File Attachments
----------------

git format-patch of initial change
  https://git.reviewboard.kde.org/media/uploaded/files/2014/01/16/298906bc-4815-45c9-ab7c-9e0d598196b5__0001-Prefer-non-empty-when-computing-include-paths.patch


Thanks,

Ben Wagner

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


More information about the KDevelop-devel mailing list