<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><pre><font face="Helvetica"><br></font></pre><pre><font face="Helvetica">Regards</font></pre><pre><br></pre></div>
<p style="color: #A0A0A8;">On Friday, 30 November, 2012 at 4:11 AM, Tobias Grosser wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><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>cfe-dev mailing list</div><div><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a></div><div><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>