[PATCH] Driver: bifurcate extended and basic MSC versioning

[Aaron Ballman]

On Tue, Jul 15, 2014 at 11:30 AM, Saleem Abdulrasool
<compnerd at compnerd.org> wrote:
> On Tue, Jul 15, 2014 at 5:54 AM, Aaron Ballman <aaron.ballman at gmail.com>
> 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).
>
>
> 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.

I am happy with this name as well. Once I realized how it fits in with
-fms-compatibility, it made sense to me. (Somehow I missed this with
Alp's email when he suggested it on Jul 1). So either
-fmsc-full-version or -fms-compatibility-version is acceptable to me.

~Aaron