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

[Manuel Klimek]

On Fri, Aug 23, 2013 at 9:43 PM, Kim Gräsman <kim.grasman at gmail.com> wrote:

> 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).
>

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.


> 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.
>

As I said, putting findInputFiles into a better place (probably the driver
library) would make sense, if somebody wants to tackle it :)

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130826/97f150f3/attachment.html>