[cfe-dev] JSONCompilationDB Parser

[Manuel Klimek]

On Mon, Dec 3, 2012 at 2:01 PM, Tobias Grosser <tobias at grosser.es> wrote:

> On 12/03/2012 01:24 PM, Chandler Carruth wrote:
>
>> On Mon, Dec 3, 2012 at 4:04 AM, Tobias Grosser <tobias at grosser.es
>> <mailto:tobias at grosser.es>> wrote:
>>
>>     On 12/03/2012 08:05 AM, Manuel Klimek wrote:
>>
>>         On Fri, Nov 30, 2012 at 9:26 AM, ramneek
>>         <onewastedlife at gmail.com <mailto:onewastedlife at gmail.**com<onewastedlife at gmail.com>
>> >
>>         <mailto:onewastedlife at gmail.__**com
>>
>>         <mailto:onewastedlife at gmail.**com <onewastedlife at gmail.com>>>>
>> wrote:
>>
>>              Would it be ok if i worked on a patch to move things to a
>>         namespace
>>              for the first cut while we decide how we can allow plugins.
>>              Also we should be ignoring the namespaces that we are not
>>         using so
>>              it allows applications to add their custom data to while
>>         preserving
>>              the acceptable file format.
>>
>>              My proposal is actually simple:
>>
>>              This is what we have today:
>>
>>              [
>>                 {"directory":"/home/user/llvm/**__build",
>>
>>         "command":"/usr/bin/clang++ -Irelative -DSOMEDEF='\"With spaces
>>         and quotes.\"'  -c -o file.o file.cc",
>>         "file":"file.cc"  },
>>                 …
>>              ]
>>
>>              We can move it to (cc = compile commands):
>>
>>              {"cc"  :{"directory":"/home/user/__**llvm/build",
>>
>>
>>         "command":"/usr/bin/clang++ -Irelative -DSOMEDEF='\"With spaces
>>         and quotes.\"'  -c -o file.o file.cc",
>>         "file":"file.cc"  },
>>                 …
>>              ]
>>
>>
>>              One thing that we will have to be careful about is that we
>>         will have to patch the cmake compilation command generation
>>         facility as well..
>>
>>              I can look into that as well or make the change such that
>>         it is backwards compatible?
>>
>>
>>         I'm still torn. While I see the arguments for why being strict
>>         might be
>>         a problem if we plan to change the format, I don't understand
>>         the need
>>         for the namespace / being able to have different things in a
>>         single file
>>         yet.
>>
>>
>>     I also have no opinion about name spaces. However, I think it would be
>>     good if we could ensure clang 3.2 just ignores unknown content.
>>     Otherwise, the costs of adding new information to that file will be
>>     a lot higher.
>>
>>     Manuel, do you think this change would still be OK for 3.2?
>>
>>
>> Folks, 3.2 is essentially shipped. This should *not* hold up that release.
>>
>
> Agreed. This is really not a release blocker.
>
> On the other hand, as this is a very non-critical component, getting this
> small change in may still be possible, and it may make our life a little
> simpler in the future. To my knowledge, there is another rc3 scheduled for
> Wednesday, so that could be the last window to get trivial changes in.
>
> Manuel, as you are the tooling stuff expert, I leave the decision to you.
> I did my job of raising the topic. ;-)
>

I agree with Chandler that trying to get this into 3.2 is not going to be
worth the effort. We should rather discuss the merits of the approaches on
a principled basis and make that decision going forward.

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121204/0e5ade1f/attachment.html>