r211420 - Driver: enhance MSC version compatibility

[Reid Kleckner]

On Mon, Jun 30, 2014 at 3:33 PM, Alp Toker <alp at nuanti.com> wrote:

>
> On 01/07/2014 01:28, Saleem Abdulrasool wrote:
>
>> On Jun 30, 2014, at 2:10 PM, Alp Toker <alp at nuanti.com> wrote:
>>
>>  On 23/06/2014 23:02, Reid Kleckner wrote:
>>>
>>>> On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker <alp at nuanti.com <mailto:
>>>> alp at nuanti.com>> wrote:
>>>>
>>>>     Please split out and name the new dotted form something like
>>>>     "-msc-full-version" to avoid ambiguity.
>>>>
>>>>
>>>> I was inclinded to overload the option because it means we don't have
>>>> to diagnose this case: -fmsc-version -fmsc-full-version=17.00.0.  We just
>>>> do the obvious thing of "last one always wins".  Diagnosing the conflict
>>>> isn't too hard, though, so let's just split the options and do exactly that
>>>> in the driver.
>>>>
>>> Saleem,
>>>
>>> Do you plan to make that change? If not I guess I can look into it..
>>>
>> Yes, I was waiting for a response to my last message about what we want
>> to call the option.
>>
>
> The proposal was -msc-full-version because it aligns at least a little
> with the documentation on MSDN.
>
>
>
>>  The reason is that this blocks some other fixes I have related to
>>> -msc-ver and the diagnostic engine.
>>>
>> Ill call it -fmsc-version-ex then for now and we can bike shed it later
>> if we want.
>>
>
> What does -ex signify? Not familiar with that naming scheme.
>
> Anyway, it seems best to go with the working name -msc-full-version unless
> something better comes along.


You mentioned that you think two 32-bit ints is the right representation
for this.  What do you think of -fmsc-version and -fmsc-build-number?  Then
there is no need to diagnose anything, with the potential exception of very
large build numbers that don't fit into _MSC_FULL_VERSION.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140630/d7103e39/attachment.html>