<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr">On Mon, Dec 3, 2012 at 4:04 AM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank" class="cremed">tobias@grosser.es</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/03/2012 08:05 AM, Manuel Klimek wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Fri, Nov 30, 2012 at 9:26 AM, ramneek <<a href="mailto:onewastedlife@gmail.com" target="_blank" class="cremed">onewastedlife@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:onewastedlife@gmail.com" target="_blank" class="cremed">onewastedlife@gmail.<u></u>com</a>>> wrote:<br>
<br>
    Would it be ok if i worked on a patch to move things to a namespace<br>
    for the first cut while we decide how we can allow plugins.<br>
    Also we should be ignoring the namespaces that we are not using so<br>
    it allows applications to add their custom data to while preserving<br>
    the acceptable file format.<br>
<br>
    My proposal is actually simple:<br>
<br>
    This is what we have today:<br>
<br>
    [<br>
       {"directory":"/home/user/llvm/<u></u>build",<br>
         "command":"/usr/bin/clang++ -Irelative -DSOMEDEF='\"With spaces and quotes.\"'  -c -o file.o file.cc",<br>
         "file":"file.cc"  },<br>
       …<br>
    ]<br>
<br>
    We can move it to (cc = compile commands):<br>
<br>
    {"cc"  :{"directory":"/home/user/<u></u>llvm/build",<br>
<br>
         "command":"/usr/bin/clang++ -Irelative -DSOMEDEF='\"With spaces and quotes.\"'  -c -o file.o file.cc",<br>
         "file":"file.cc"  },<br>
       …<br>
    ]<br>
<br>
<br>
    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..<br>
<br>
    I can look into that as well or make the change such that it is backwards compatible?<br>
<br>
<br>
I'm still torn. While I see the arguments for why being strict might be<br>
a problem if we plan to change the format, I don't understand the need<br>
for the namespace / being able to have different things in a single file<br>
yet.<br>
</div></blockquote>
<br>
I also have no opinion about name spaces. However, I think it would be<br>
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.<br>
<br>
Manuel, do you think this change would still be OK for 3.2?</blockquote><div><br></div><div style>Folks, 3.2 is essentially shipped. This should *not* hold up that release.</div><div style><br></div><div style>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.<br>
</div><div style><br></div><div style>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.</div>
<div style><br></div><div style><br></div><div style>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.</div></div></div>
</div></div>