As another include-what-you-use maintainer I support the proposal. I am doing so solely in my personal capacity and am not representing any third parties.<br><br>Regards,<br>Volodymyr <br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 4, 2017 at 13:41 Kim Gräsman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
This is a proposal to integrate include-what-you-use [1] into clang-tools-extra.<br>
<br>
# Background<br>
The include-what-you-use tool analyzes #includes in C and C++ files and<br>
recommends how to improve them. The goal is to capture symbol dependencies in<br>
code and produce the minimal set of #includes to satisfy these symbol<br>
dependencies. For more information you can check the project site [2], docs, and<br>
presentation from 2010 LLVM Developers' Meeting [3].<br>
<br>
# Benefits<br>
Migration to clang-tools-extra doesn't come without a cost, so I want to list<br>
some of the benefits this move yields.<br>
<br>
## For Clang community<br>
* Ability to reuse some of IWYU analysis for other purposes. Currently IWYU is<br>
distributed as a CLI tool and has no API but it is possible to split out a<br>
separate library. I think there could be some integration potential with the<br>
budding refactoring tools, for example.<br>
* More community input in deciding further IWYU direction to help it to be more<br>
useful for various parties.<br>
<br>
## For include-what-you-use users<br>
* Easier distribution and use. For users already using other Clang tools it<br>
should be easier to use IWYU as any other Clang tool. I also expect it to make<br>
life easier for people packaging include-what-you-use for various *nix<br>
distributions.<br>
* Moving the tool towards consistency with other Clang tools.<br>
<br>
## For include-what-you-use project<br>
* Exposure to more users.<br>
* Easier release process. Instead of releasing IWYU separately, it could be<br>
bundled with LLVM+Clang releases. It shouldn't incur more work for LLVM+Clang<br>
releases as the main complexity comes from tracking different branches and<br>
building binaries for different platforms.<br>
* More resiliency as the project becomes more community-owned instead of<br>
personally-owned.<br>
<br>
# Potential downsides<br>
When new Clang sub-projects are proposed, one of the most common concerns is the<br>
maintenance burden. Dumping the code and walking away to let the community<br>
support the code is unacceptable. The longevity of the project demonstrates<br>
commitment to maintaining the project. The history on GitHub shows that<br>
include-what-you-use is not a passing fancy that will be discarded and forgotten<br>
in a week or two.<br>
<br>
What is your opinion, is there value in having include-what-you-use in<br>
clang-tools-extra?<br>
<br>
Thanks for any input,<br>
- Kim<br>
<br>
[1] <a href="https://github.com/include-what-you-use/include-what-you-use" rel="noreferrer" target="_blank">https://github.com/include-what-you-use/include-what-you-use</a><br>
[2] <a href="https://include-what-you-use.org/" rel="noreferrer" target="_blank">https://include-what-you-use.org/</a><br>
[3] <a href="http://llvm.org/devmtg/2010-11/" rel="noreferrer" target="_blank">http://llvm.org/devmtg/2010-11/</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>