[cfe-dev] JSONCompilationDB Parser

[ramneek]

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?

Regards


On Friday, 30 November, 2012 at 4:11 AM, Tobias Grosser wrote:

> On 11/29/2012 08:42 PM, David Blaikie wrote:
> > If we really want to do this to deliberately allow 3rd party fields in
> > the database it's probably worthwhile having some kind of defined
> > namespace (either for our names or for the 3rd party names) so that
> > future extensions to our schema don't conflict with 3rd party fields.
> >  
>  
>  
> Having namespaces for third-party plugins is a good idea.
>  
> > (& in that case we could still hard-error (if we want to) on fields in
> > our namespace that are unknown (Tobias's position to be considered -
> > only works if new fields are always acceptable to be ignored))
> >  
>  
>  
> Regarding our (or the global) namespace, it would be interesting to know  
> if we expect additions that are not acceptable to be ignored. I assumed  
> additional fields provide additional information that would just be  
> missing if the fields are not read. Similar to libclang.so we could  
> provide additional information in new fields, but we could agree to not  
> change the semantics of existing fields.
>  
> I am mainly concerned about backwards compatibility issues. It may be  
> helpful to clarify if we want to remain compatible with older versions  
> of clang and in case we do, how we want to ensure compatibility. Is my  
> understanding correct that the current code will make clang versions  
> error out, in case they read a compilation database that includes  
> extensions we may possibly add ourselves at some point in the future? In  
> case this is true, how would we handle such a situation? Are there other  
> solutions than requiring the user to upgrade to the most recent version  
> of clang (possibly not yet in his package repository or not installed by  
> his sysadmins)?
>  
> Cheers
> Tobi
>  
>  
>  
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu (mailto:cfe-dev at cs.uiuc.edu)
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121130/3c039dde/attachment.html>