IWYU command-line wishes (was Re: [PATCH] Header dependencies support for modularize)

[Kim Gräsman]

On Fri, Aug 23, 2013 at 10:59 AM, Manuel Klimek <klimek at google.com> wrote:
>
>> Though I think IWYU was purposefully designed to NOT run together with
>> a normal build because
>>
>> 1) you couldn't re-run it without an intervening ``make clean``
>> 2) it would be take at least as long as building the software and if
>> you're not IWYU-clean, that's not something you want to do
>> unnecessarily :-)
>>
>> I wasn't around when the current strategy was set, but I think it was
>> directed by these two goals and the absence of the Tooling library at
>> the time.
>
> I understood it in a way that you wanted to run IWYU as part of a
> make-build, and that was why you wanted to not run it as a standalone tool
> with a compilation db. I'm confused now :)

I'm sorry, it seems difficult for me to articulate this clearly.

Currently, IWYU can be run in a make-build as a replacement for clang.
There's a trick where we always fail so that users can use make -k to
force IWYU to run over the entire code base (see
https://code.google.com/p/include-what-you-use/wiki/InstructionsForUsers#How_to_Run).
Make is really only used to provide IWYU with compiler arguments.

I would like to add compilation-database support as a different mode,
where we can list one or more source or header files to process. There
are cases where it's hard to force the make build to do what we want
(e.g. shared headers, included by multiple source files), where it
would make more sense to process them explicitly, maybe
subtree-at-a-time. Some form of compilation db would be necessary to
get the compiler args in place, as the build system is out of the
picture.

Finally, I would like to wedge both of those modes into the Tooling
framework, because it's being actively maintained and we should be
able to pick up improvements as they appear.

But Tooling seems built on the idea that source files are specified as
tool arguments (before the double-dash), even if they are later
specified as Clang input (after the double-dash).

John's latest patch was exactly what I was looking for, however: if
findInputFile(s) was part of Tooling proper, I could use it to unpack
the inputs from the Clang command-line and feed it into ClangTool.

Thanks,
- Kim