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). 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
