[cfe-commits] [PATCH] Adds a FixedCompilationDatabase

[Manuel Klimek]

Marshall, anything to add, or does this satisfy your requirements?

Thanks,
/Manuel

On Wed, Apr 11, 2012 at 1:23 AM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Apr 10, 2012, at 4:23 PM, Manuel Klimek <klimek at google.com> wrote:
>
>> On Tue, Apr 10, 2012 at 10:07 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>>
>>> On Apr 10, 2012, at 1:05 PM, Manuel Klimek <klimek at google.com> wrote:
>>>
>>>> On Tue, Apr 10, 2012 at 7:54 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>>>>
>>>>> On Apr 10, 2012, at 5:17 AM, Manuel Klimek <klimek at google.com> 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