On 01/07/2014 01:38, Reid Kleckner wrote:
On Mon, Jun 30, 2014 at 3:33 PM, Alp Toker <[email protected]
<mailto:[email protected]>> wrote:
On 01/07/2014 01:28, Saleem Abdulrasool wrote:
On Jun 30, 2014, at 2:10 PM, Alp Toker <[email protected]
<mailto:[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]>
<mailto:[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.
I only meant it in so far as the representation could simplify the bit
flipping and storage in LangOpts. The old -fmsc-version was always rough
because it exposed a detail that isn't relevant to users or particularly
visible, so it'll be nice to deprecate.
As for the version value we receive from users and tools, I'm pretty
sure one single input version is the right format.
That value's going to come from one of these places:
1) IDE integration, e.g. LLVM's
tools/msbuild/Microsoft.Cpp.Win32.llvm.props.in
2) Manually taken from the user typing cl.exe /help and copy-pasting the
version number as an argument to clang.
3) Manually taken from online documentation and passed as an argument to
clang.
In practice we should make sure the format satisfies those use cases. I
haven't confirmed but I'm hopeful the dotted format is all we need.
Alp.
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
