[cfe-dev] JSONCompilationDB Parser

[David Blaikie]

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.

(& 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))

On Thu, Nov 29, 2012 at 11:31 AM, Manuel Klimek <klimek at google.com> wrote:
> On Thu, Nov 29, 2012 at 11:25 AM, Tobias Grosser <tobias at grosser.es> wrote:
>>
>> On 11/29/2012 06:44 PM, Manuel Klimek wrote:
>>>
>>> Hi Ramneek,
>>>
>>> On Thu, Nov 29, 2012 at 7:19 AM, Ramneek Handa <ramneekhanda at gmail.com
>>> <mailto:ramneekhanda at gmail.com>> wrote:
>>>
>>>     Why is it so strict? I am trying to write an ide backend would like
>>>     to use the compilation commands file to contain some extra
>>>     information so that i don't have to keep multiple files. the
>>>     following code in parse message doesn't allow me to keep any other
>>>     key but directory, command and file.
>>>
>>>     else {
>>>              ErrorMessage = ("Unknown key: \"" +
>>>                              KeyString->getRawValue() + "\"").str();
>>>              return false;
>>>            }
>>>
>>>     Could this be removed?
>>>
>>> In my experience being strict is better in the long run. It allows us to
>>> extend the format without the need to worry about clashing names with
>>> other mixed formats, and it surfaces errors early instead of hiding them.
>>>
>>> Is there a reason why having multiple files is a problem?
>>
>>
>> Hi Manuel,
>>
>> I see your point. However, being strict has one large problem. If we at
>> some point decide to add additional information to the compilation database,
>> all previously released libclang tools will break. This means, this
>> restriction makes it even for ourselves unnecessarily hard and disruptive to
>> extend the compilation db format.
>> If possible, I would be very much in favor of removing this restriction
>> even before clang 3.2.
>
>
> If multiple people vote for it, I can most certainly be convinced
> otherwise...
>
> Cheers,
> /Manuel
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>