On Tue, Apr 10, 2012 at 7:54 PM, Douglas Gregor <[email protected]> wrote: > > On Apr 10, 2012, at 5:17 AM, Manuel Klimek <[email protected]> wrote: > >> Added parsing code and integrated it into clang-check (which I'm now >> heavily testing in my vim session :) >> >> As a nice side effect this gives us a beautiful way to write FileCheck >> integration tests for clang tools. >> I'd still like to be able to pull something out that encapsulates most >> of the command line parsing for tools, so it's less code, but I want >> to leave that for later. > > Patch generally looks good, although this… > > +std::vector<CompileCommand> > +FixedCompilationDatabase::getCompileCommands(StringRef FilePath) const { > + std::vector<CompileCommand> Result(CompileCommands); > + Result[0].CommandLine.push_back(FilePath); > + return Result; > +} > > doesn't actually seem right. What if the CompileCommands contains multiple > source files, e.g., > > clang-check -- a.cpp b.cpp > > shouldn't we filter out the other non-source files, or return an empty > compile command if the command line didn't specify the given file name (say, > if the CompilationDatabase is asked to return a compile command for c.cpp)?
I tried to document that in the chandler-length comments of the FixedCompilationDatabase, but apparently I failed :) The idea is that you'll specify the TUs to work on, the same way you do for other clang tools, before the "--". Your example would be clang-check . a.cpp b.cpp -- -c ... Currently specifying positional parameters after the -- is not supported. I think we'll want to allow that in the future, but I also think that we'll still want to provide the simple interface we have now. Tools will always be somewhat special in that we only allow one compile action per tool running over a source. Thoughts? /Manuel _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
