<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">On Thu, Nov 29, 2012 at 11:25 AM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</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 class="im">On 11/29/2012 06:44 PM, Manuel Klimek wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hi Ramneek,<br>
<br>
On Thu, Nov 29, 2012 at 7:19 AM, Ramneek Handa <<a href="mailto:ramneekhanda@gmail.com" target="_blank">ramneekhanda@gmail.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:ramneekhanda@gmail.com" target="_blank">ramneekhanda@gmail.com</a><u></u>>> wrote:<br>
<br>
    Why is it so strict? I am trying to write an ide backend would like<br>
    to use the compilation commands file to contain some extra<br>
    information so that i don't have to keep multiple files. the<br>
    following code in parse message doesn't allow me to keep any other<br>
    key but directory, command and file.<br>
<br>
    else {<br>
             ErrorMessage = ("Unknown key: \"" +<br>
                             KeyString->getRawValue() + "\"").str();<br>
             return false;<br>
           }<br>
<br>
    Could this be removed?<br>
<br>
In my experience being strict is better in the long run. It allows us to<br>
extend the format without the need to worry about clashing names with<br>
other mixed formats, and it surfaces errors early instead of hiding them.<br>
<br>
Is there a reason why having multiple files is a problem?<br>
</div></div></blockquote>
<br>
Hi Manuel,<br>
<br>
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.<br>

If possible, I would be very much in favor of removing this restriction even before clang 3.2.<br></blockquote><div><br></div><div>If multiple people vote for it, I can most certainly be convinced otherwise...</div><div>
<br></div><div>Cheers,</div><div>/Manuel</div></div></div></div>