[PATCH] Driver: bifurcate extended and basic MSC versioning

[Aaron Ballman]

On Tue, Jul 15, 2014 at 9:27 AM, Alp Toker <alp at nuanti.com> wrote:
>
> On 15/07/2014 15:54, Aaron Ballman wrote:
>>
>> On Mon, Jul 14, 2014 at 4:37 PM, Alp Toker <alp at nuanti.com> wrote:
>>>
>>> On 01/07/2014 23:02, Aaron Ballman wrote:
>>>>
>>>> On Tue, Jul 1, 2014 at 3:50 PM, Alp Toker <alp at nuanti.com> wrote:
>>>>>
>>>>> On 01/07/2014 22:40, Aaron Ballman wrote:
>>>>>>
>>>>>> On Tue, Jul 1, 2014 at 3:15 PM, Alp Toker <alp at nuanti.com> wrote:
>>>>>>>
>>>>>>> On 01/07/2014 21:53, Aaron Ballman wrote:
>>>>>>>>>
>>>>>>>>> +1 for -fmsc-full-version.
>>>>>>>>
>>>>>>>> What about -fmsc-extended-version?
>>>>>>>>
>>>>>>>> I ask because Saleem pointed out in IRC that this really isn't the
>>>>>>>> full version (it doesn't include the build number).
>>>>>>>
>>>>>>>
>>>>>>> It's only a temporary bug that the build number is ignored, and
>>>>>>> that'll
>>>>>>> will
>>>>>>> go away as soon as we add a second variable or more bits to LangOpts.
>>>>>>
>>>>>> I apologize, I wasn't entirely clear with my complaint. Okay, in
>>>>>> reality, I was pretty obtuse. :-) It's that it is optionally full
>>>>>> information (it doesn't require the full information to be present).
>>>>>> Eg) -fmsc-full-version=17
>>>>>>
>>>>>>> The input really is the MSC full version so -fmsc-full-version is the
>>>>>>> sensible name. Let's not invent new terminology like "extended
>>>>>>> version"
>>>>>>> here.
>>>>>>
>>>>>> There are zero options with "full" in their name. There are two-ish
>>>>>> options with "extended" in their name (fextended-identifiers and
>>>>>> fno-extended-identifiers), but they don't really qualify as examples
>>>>>> for this discussion. So both of these choices would qualify as
>>>>>> "inventing new terminology."
>>>>>>
>>>>>> The goal is to discuss what qualifies as a "sensible" name, and I have
>>>>>> some (relatively weak, but valid) objections to using "full" because
>>>>>> it implies you are required to specify the full version information
>>>>>> when that isn't the case.
>>>>>
>>>>>
>>>>> Oh, I see what you were getting at now.
>>>>>
>>>>> I *do* think that's a valid point given that we accept less than the
>>>>> full
>>>>> version to be written, but in principle we expect people/tools to pass
>>>>> a
>>>>> verbatim and long dotted version here with shorter forms accepted just
>>>>> "because we can".
>>>>
>>>> "Expect" and "will actually happen" doesn't always match up. ;-)
>>>>
>>>>> And that's weighed up against the stronger argument that this gets
>>>>> converted
>>>>> to an _MSC_FULL_VER, and that the documentation calls it the full
>>>>> version.
>>>>> So there's a really neat self-documenting property to -msc-full-version
>>>>
>>>> That is true. But it also sets more than just _MSC_FULL_VER, and what
>>>> gets set here is not exactly what gets pushed into _MSC_FULL_VER.
>>>>
>>>>> As for -msc-extended-version, the version we accept isn't really an
>>>>> extension, not is it an extended form of anything, given that it can
>>>>> (a)
>>>>> be
>>>>> short as you pointed out yourself and (b) -msc-version is crummy and
>>>>> due
>>>>> for
>>>>> deprecation, so we don't want to express the nice new flag as an
>>>>> extended
>>>>> form of something that's going away and irrelevant to new users.
>>>>
>>>> It is true that this isn't really an extension either.
>>>>
>>>>> For those reasons I'm getting good vibes about -msc-full-version
>>>>
>>>> I'm still not there yet. But I'm getting slightly worse vibes about
>>>> -fmsc-extended-version. ;-)
>>>
>>>
>>> We're generally hovering around -msc-full-version then?
>>
>> I don't think we have strong consensus on any name. But since I had
>> the strongest objections, I'll get the ball rolling by saying
>> msc-full-version is reasonable enough. My objections were that the
>> name wasn't perfectly descriptive of the functionality, but as more
>> names are being proposed, I am starting to think no name will be
>> perfectly descriptive of the functionality aside from the name we're
>> replacing (and can't use).
>>
>> Assuming Reid still likes the name, I think that gives us at least
>> weak consensus on msc-full-version.
>>
>>> Let's fix forward instead of dropping this patchset from 3.5. Please
>>> commit
>>> once Aaron gives a nod
>>
>> I don't think "fix-forward" is something we want to do here (I
>
>
> What I mean is, let's not leave the tree in its current in-between state for
> too long, with a release round the corner. Either back out the original
> patch or fix-forward.

Ahhhh, that makes far more sense to me. I definitely agree. :-)

~Aaron