<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 4:25 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="">On Tue, Aug 12, 2014 at 04:18:47PM -0700, Chandler Carruth wrote:<br>
> On Tue, Aug 12, 2014 at 3:41 PM, Dylan Noblesmith <<a href="mailto:nobled@dreamwidth.org">nobled@dreamwidth.org</a>><br>
> wrote:<br>
><br>
> > Since clients shouldn't (and shouldn't be able to)<br>
> > include LLVM's internal config.h header, it was<br>
> > effectively completely useless there.<br>
> ><br>
> > Put it where LLVM_VERSION_MAJOR and LLVM_VERSION_MINOR<br>
> > already are instead.<br>
> ><br>
><br>
> But, the whole point was that it is *different*. There shouldn't ever be<br>
> API breaking changes in a patch release? The point of patch releases were<br>
> to apply minimal, targeted fixes for critical bugs. Clients shouldn't be<br>
> aware of them IMO.<br>
<br>
</div></div>They might still want to be able to workaround bugs fixed by those<br>
targeted patches for critical bugs :)</blockquote></div><br>As the fix might arrive with the same SO name, I would not expect this to be done via macros.</div></div>