[PATCH] Driver: bifurcate extended and basic MSC versioning

[Saleem Abdulrasool]

On Tue, Jul 15, 2014 at 6:27 AM, Alp Toker <alp at nuanti.com> wrote:

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


The change is not based on theory, it is addressing an actual issue with
use of newer Microsoft SDKs.  What you are proposing is that we knowingly
make clang incompatible with a released SDK in order to accommodate a
theoretical IDE's use.  I understand that this may make it more difficult
for you, but, I think that making clang incompatible with a released SDK is
a worse choice here.


>
>  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
>
>
-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140715/080a8876/attachment.html>