[cfe-dev] JSONCompilationDB Parser

[Chandler Carruth]

On Mon, Dec 3, 2012 at 4:04 AM, Tobias Grosser <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>>> 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.

I don't think that the clang tools are sufficiently mature to really spend
a lot of time or effort trying to make the 3.2 release versions of the
tools work with future build systems and/or IDEs. If we wanted this to be
true, we should have done a lot more testing of these tools prior to the
release.

I think we should make including a collection of clang-based tools a target
for the 3.3 release, and try to actually advertise the fact that we're
going to try to do this, test them thoroughly, and of course both make and
document these types of decisions. But not 3.2, it's too late in the
release game to start thinking about this IMO.


Note that I am not (yet) taking a stance about the actual issue this patch
is trying to address here, just about the release implications or lack
thereof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121203/ccd35237/attachment.html>