<div dir="ltr">On Fri, Aug 23, 2013 at 9:43 PM, Kim Gräsman <span dir="ltr"><<a href="mailto:kim.grasman@gmail.com" target="_blank">kim.grasman@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 23, 2013 at 10:59 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>

><br>
>> Though I think IWYU was purposefully designed to NOT run together with<br>
>> a normal build because<br>
>><br>
>> 1) you couldn't re-run it without an intervening ``make clean``<br>
>> 2) it would be take at least as long as building the software and if<br>
>> you're not IWYU-clean, that's not something you want to do<br>
>> unnecessarily :-)<br>
>><br>
>> I wasn't around when the current strategy was set, but I think it was<br>
>> directed by these two goals and the absence of the Tooling library at<br>
>> the time.<br>
><br>
> I understood it in a way that you wanted to run IWYU as part of a<br>
> make-build, and that was why you wanted to not run it as a standalone tool<br>
> with a compilation db. I'm confused now :)<br>
<br>
I'm sorry, it seems difficult for me to articulate this clearly.<br>
<br>
Currently, IWYU can be run in a make-build as a replacement for clang.<br>
There's a trick where we always fail so that users can use make -k to<br>
force IWYU to run over the entire code base (see<br>
<a href="https://code.google.com/p/include-what-you-use/wiki/InstructionsForUsers#How_to_Run" target="_blank">https://code.google.com/p/include-what-you-use/wiki/InstructionsForUsers#How_to_Run</a>).<br>
Make is really only used to provide IWYU with compiler arguments.<br>
<br>
I would like to add compilation-database support as a different mode,<br>
where we can list one or more source or header files to process. There<br>
are cases where it's hard to force the make build to do what we want<br>
(e.g. shared headers, included by multiple source files), where it<br>
would make more sense to process them explicitly, maybe<br>
subtree-at-a-time. Some form of compilation db would be necessary to<br>
get the compiler args in place, as the build system is out of the<br>
picture.<br>
<br>
Finally, I would like to wedge both of those modes into the Tooling<br>
framework, because it's being actively maintained and we should be<br>
able to pick up improvements as they appear.<br>
<br>
But Tooling seems built on the idea that source files are specified as<br>
tool arguments (before the double-dash), even if they are later<br>
specified as Clang input (after the double-dash).<br></blockquote><div><br></div><div>I'm still not sure what exactly the problem is. It seems to me like you could implement a clang-tool and a clang plugin with very little overhead.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
John's latest patch was exactly what I was looking for, however: if<br>
findInputFile(s) was part of Tooling proper, I could use it to unpack<br>
the inputs from the Clang command-line and feed it into ClangTool.<br></blockquote><div><br></div><div>As I said, putting findInputFiles into a better place (probably the driver library) would make sense, if somebody wants to tackle it :)</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div></div></div></div>