On Mon, Jun 30, 2014 at 3:33 PM, Alp Toker <[email protected]> wrote: > > On 01/07/2014 01:28, Saleem Abdulrasool wrote: > >> On Jun 30, 2014, at 2:10 PM, Alp Toker <[email protected]> wrote: >> >> On 23/06/2014 23:02, Reid Kleckner wrote: >>> >>>> On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker <[email protected] <mailto: >>>> [email protected]>> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
