On Fri, Aug 23, 2013 at 9:43 PM, Kim Gräsman <[email protected]> wrote:
> On Fri, Aug 23, 2013 at 10:59 AM, Manuel Klimek <[email protected]> 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
