[PATCH] Driver: bifurcate extended and basic MSC versioning

[Alp Toker]

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.

> understand option names tend to be long-lived, much like our C API
> interfaces, for compatibility reasons). We either want to live with
> this name for a long, long time, or we hold off for a bit longer on
> the patch. That being said, if there aren't any further objections,
> I'm happy for this to go in.
>
> ~Aaron

-- 
http://www.nuanti.com
the browser experts