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
