[PATCH] Driver: bifurcate extended and basic MSC versioning

[Alp Toker]

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?

Let's fix forward instead of dropping this patchset from 3.5. Please 
commit once Aaron gives a nod


>
> ~Aaron

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