<div dir="ltr">On Tue, Jul 15, 2014 at 5:54 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron.ballman@gmail.com" target="_blank">aaron.ballman@gmail.com</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="HOEnZb"><div class="h5">On Mon, Jul 14, 2014 at 4:37 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>

><br>
> On 01/07/2014 23:02, Aaron Ballman wrote:<br>
>><br>
>> On Tue, Jul 1, 2014 at 3:50 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>
>>><br>
>>> On 01/07/2014 22:40, Aaron Ballman wrote:<br>
>>>><br>
>>>> On Tue, Jul 1, 2014 at 3:15 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>
>>>>><br>
>>>>> On 01/07/2014 21:53, Aaron Ballman wrote:<br>
>>>>>>><br>
>>>>>>> +1 for -fmsc-full-version.<br>
>>>>>><br>
>>>>>> What about -fmsc-extended-version?<br>
>>>>>><br>
>>>>>> I ask because Saleem pointed out in IRC that this really isn't the<br>
>>>>>> full version (it doesn't include the build number).<br>
>>>>><br>
>>>>><br>
>>>>> It's only a temporary bug that the build number is ignored, and that'll<br>
>>>>> will<br>
>>>>> go away as soon as we add a second variable or more bits to LangOpts.<br>
>>>><br>
>>>> I apologize, I wasn't entirely clear with my complaint. Okay, in<br>
>>>> reality, I was pretty obtuse. :-) It's that it is optionally full<br>
>>>> information (it doesn't require the full information to be present).<br>
>>>> Eg) -fmsc-full-version=17<br>
>>>><br>
>>>>> The input really is the MSC full version so -fmsc-full-version is the<br>
>>>>> sensible name. Let's not invent new terminology like "extended version"<br>
>>>>> here.<br>
>>>><br>
>>>> There are zero options with "full" in their name. There are two-ish<br>
>>>> options with "extended" in their name (fextended-identifiers and<br>
>>>> fno-extended-identifiers), but they don't really qualify as examples<br>
>>>> for this discussion. So both of these choices would qualify as<br>
>>>> "inventing new terminology."<br>
>>>><br>
>>>> The goal is to discuss what qualifies as a "sensible" name, and I have<br>
>>>> some (relatively weak, but valid) objections to using "full" because<br>
>>>> it implies you are required to specify the full version information<br>
>>>> when that isn't the case.<br>
>>><br>
>>><br>
>>> Oh, I see what you were getting at now.<br>
>>><br>
>>> I *do* think that's a valid point given that we accept less than the full<br>
>>> version to be written, but in principle we expect people/tools to pass a<br>
>>> verbatim and long dotted version here with shorter forms accepted just<br>
>>> "because we can".<br>
>><br>
>> "Expect" and "will actually happen" doesn't always match up. ;-)<br>
>><br>
>>> And that's weighed up against the stronger argument that this gets<br>
>>> converted<br>
>>> to an _MSC_FULL_VER, and that the documentation calls it the full<br>
>>> version.<br>
>>> So there's a really neat self-documenting property to -msc-full-version<br>
>><br>
>> That is true. But it also sets more than just _MSC_FULL_VER, and what<br>
>> gets set here is not exactly what gets pushed into _MSC_FULL_VER.<br>
>><br>
>>> As for -msc-extended-version, the version we accept isn't really an<br>
>>> extension, not is it an extended form of anything, given that it can (a)<br>
>>> be<br>
>>> short as you pointed out yourself and (b) -msc-version is crummy and due<br>
>>> for<br>
>>> deprecation, so we don't want to express the nice new flag as an extended<br>
>>> form of something that's going away and irrelevant to new users.<br>
>><br>
>> It is true that this isn't really an extension either.<br>
>><br>
>>> For those reasons I'm getting good vibes about -msc-full-version<br>
>><br>
>> I'm still not there yet. But I'm getting slightly worse vibes about<br>
>> -fmsc-extended-version. ;-)<br>
><br>
><br>
> We're generally hovering around -msc-full-version then?<br>
<br>
</div></div>I don't think we have strong consensus on any name. But since I had<br>
the strongest objections, I'll get the ball rolling by saying<br>
msc-full-version is reasonable enough. My objections were that the<br>
name wasn't perfectly descriptive of the functionality, but as more<br>
names are being proposed, I am starting to think no name will be<br>
perfectly descriptive of the functionality aside from the name we're<br>
replacing (and can't use).<br></blockquote><div><br></div><div>Personally, I prefer -fms-compatibility-version of the other suggested names.  But, I suppose that the shed can be repainted at some point in the future.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Assuming Reid still likes the name, I think that gives us at least<br>
weak consensus on msc-full-version.<br>
<div class=""><br>
> Let's fix forward instead of dropping this patchset from 3.5. Please commit<br>
> once Aaron gives a nod<br>
<br>
</div>I don't think "fix-forward" is something we want to do here (I<br>
understand option names tend to be long-lived, much like our C API<br>
interfaces, for compatibility reasons). We either want to live with<br>
this name for a long, long time, or we hold off for a bit longer on<br>
the patch. That being said, if there aren't any further objections,<br>
I'm happy for this to go in.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span></blockquote></div><br>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>