<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">On Fri, Nov 30, 2012 at 9:26 AM, ramneek <span dir="ltr"><<a href="mailto:onewastedlife@gmail.com" target="_blank">onewastedlife@gmail.com</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>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.</div><div>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. </div>
<div><br></div><div>My proposal is actually simple:</div><div><br></div><div>This is what we have today:</div><div><pre>[
{ "directory": "/home/user/llvm/build",
"command": "/usr/bin/clang++ -Irelative -DSOMEDEF='\"With spaces and quotes.\"' -c -o file.o file.cc",
"file": "file.cc" },
…
]</pre><pre><font face="Helvetica">We can move it to (cc = compile commands):</font></pre><pre><font face="Helvetica">{ "cc" : </font>{ "directory": "/home/user/llvm/build",</pre><pre> "command": "/usr/bin/clang++ -Irelative -DSOMEDEF='\"With spaces and quotes.\"' -c -o file.o file.cc",
"file": "file.cc" },
…
]</pre><pre><br></pre><pre><font face="Helvetica">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..</font></pre><pre><font face="Helvetica">I can look into that as well or make the change such that it is backwards compatible?</font></pre>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><pre><font face="Helvetica"><br></font></pre><pre><font face="Helvetica">Regards</font></pre>
<pre><br></pre></div><div><div class="h5">
<p style="color:#a0a0a8">On Friday, 30 November, 2012 at 4:11 AM, Tobias Grosser wrote:</p>
</div></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><div><div class="h5"><div>On 11/29/2012 08:42 PM, David Blaikie wrote:</div><blockquote type="cite"><div><div>If we really want to do this to deliberately allow 3rd party fields in</div>
<div>the database it's probably worthwhile having some kind of defined</div><div>namespace (either for our names or for the 3rd party names) so that</div><div>future extensions to our schema don't conflict with 3rd party fields.</div>
</div></blockquote><div><br></div><div>Having namespaces for third-party plugins is a good idea.</div><div><br></div><blockquote type="cite"><div><div>(& in that case we could still hard-error (if we want to) on fields in</div>
<div>our namespace that are unknown (Tobias's position to be considered -</div><div>only works if new fields are always acceptable to be ignored))</div></div></blockquote><div><br></div><div>Regarding our (or the global) namespace, it would be interesting to know </div>
<div>if we expect additions that are not acceptable to be ignored. I assumed </div><div>additional fields provide additional information that would just be </div><div>missing if the fields are not read. Similar to libclang.so we could </div>
<div>provide additional information in new fields, but we could agree to not </div><div>change the semantics of existing fields.</div><div><br></div><div>I am mainly concerned about backwards compatibility issues. It may be </div>
<div>helpful to clarify if we want to remain compatible with older versions </div><div>of clang and in case we do, how we want to ensure compatibility. Is my </div><div>understanding correct that the current code will make clang versions </div>
<div>error out, in case they read a compilation database that includes </div><div>extensions we may possibly add ourselves at some point in the future? In </div><div>case this is true, how would we handle such a situation? Are there other </div>
<div>solutions than requiring the user to upgrade to the most recent version </div><div>of clang (possibly not yet in his package repository or not installed by </div><div>his sysadmins)?</div><div><br></div><div>Cheers</div>
<div>Tobi</div><div><br></div><div><br></div><div><br></div></div></div><div class="im"><div>_______________________________________________</div><div>cfe-dev mailing list</div><div><a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a></div>
<div><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></div></div></div></div></span>
</blockquote>
<div>
<br>
</div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>