[cfe-dev] JSONCompilationDB Parser

[Manuel Klimek]

On Fri, Nov 30, 2012 at 9:26 AM, ramneek <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.

Cheers,
/Manuel


>
> 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
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> cfe-dev mailing list
> 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/20121203/ebe12a7a/attachment.html>