[PATCH] Driver: bifurcate extended and basic MSC versioning

Aaron Ballman aaron.ballman at gmail.com
Tue Jul 1 13:02:33 PDT 2014


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. ;-)

~Aaron



More information about the cfe-commits mailing list