[PATCH] Driver: bifurcate extended and basic MSC versioning

[Saleem Abdulrasool]

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.


> 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
> 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
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140715/d82c78a6/attachment.html>