<div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Mar 18, 2019 at 11:08 AM Tom Honermann via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/17/2019 2:50 PM, Aaron Ballman via cfe-dev wrote:<br>
> On Sun, Mar 17, 2019 at 1:59 PM Nico Weber via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> This would basically undo <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D37272&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=oOJsFtgkFCCcDlfLWKmfrVDtpXLihXJTBGJfSapXCV0&m=NN7eJZPEoSXTgtLbDft08spwp4-8SuqJAEb82D7VQ_g&s=xAZXMyOnpVwmiNzdVbq3IST7I4DrGtNBpcnyXJWSsAI&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D37272&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=oOJsFtgkFCCcDlfLWKmfrVDtpXLihXJTBGJfSapXCV0&m=NN7eJZPEoSXTgtLbDft08spwp4-8SuqJAEb82D7VQ_g&s=xAZXMyOnpVwmiNzdVbq3IST7I4DrGtNBpcnyXJWSsAI&e=</a> which also caused lots of incremental build work after every sync (and technically, after every local commit). So if this got added, it should probably be opt-in and only be set for production builds, not for dev builds.<br>
>><br>
>> Since you can't compare git hashes, when do you imagine would __clang_commit_hash__ be useful?<br>
> As mentioned upthread, I believe this is for automated equality<br>
> comparisons, mostly. You can compare git hashes for equality, so I<br>
> guess that's useful.<br>
><br>
>> Doesn't __clang_revision_number__ solve the same problem that __has_feature() and friends solve, only in a worse way?<br>
> This one is less clear to me, especially given that we're phasing out<br>
> svn. What will this macro represent once we've fully switched away<br>
> from svn?<br>
><br>
>> In practice, I found all the __clang_major__ / __clang_minor__ etc built-ins to be useless because they're gratuitously different in Xcode's clang and there isn't a vendor id define. I suppose that's what Troy said above.<br>
> +infinity (this causes considerable problems for our tools)<br>
<br>
Likewise.  We have to parse the output of 'clang --version' to determine<br>
if the Clang version we're emulating is Apple Clang (or ARM Clang or<br>
Android Clang or ...).  It would be great to have a __clang_vendor__ or<br>
similar macro that we could rely on instead</blockquote><div><br></div>Apple Clang does set the __apple_build_version__ macro.</div></div>