Marshall, anything to add, or does this satisfy your requirements? Thanks, /Manuel
On Wed, Apr 11, 2012 at 1:23 AM, Douglas Gregor <[email protected]> wrote: > > On Apr 10, 2012, at 4:23 PM, Manuel Klimek <[email protected]> wrote: > >> On Tue, Apr 10, 2012 at 10:07 PM, Douglas Gregor <[email protected]> wrote: >>> >>> On Apr 10, 2012, at 1:05 PM, Manuel Klimek <[email protected]> wrote: >>> >>>> 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 :) >>> >>> I just missed it, sorry. >>> >>>> 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 ... >>> >>> >>> I can live with that, although I'll note that it's still a little >>> unfortunate that I can't drop in "clang-check" as if it were a compiler and >>> have it do the right thing. >> >> Yep, I generally agree. The problem is that then we have to be able to >> parse a compile command line, which according to Chandler means to let >> the Driver create a Compiler instance, and then using that to drive >> the tool. I'm not sure how this would turn out architecture wise, and >> I don't expect it to be very important, as, if you want to run the >> tool like a compiler, just use a clang plugin - that's what they're >> really good at :) > > Fair point. Carry on ;) > > - Doug _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
