[cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
beanz at apple.com
Fri Aug 22 11:01:06 PDT 2014
> On Aug 22, 2014, at 10:09 AM, Daniel Dilts <diltsman at gmail.com> wrote:
> On Fri, Aug 22, 2014 at 9:58 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote:
>> On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com <mailto:diltsman at gmail.com>> wrote:
>> On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote:
>> Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to 2013. The motivating reason is this will allow us to take advantage of a bunch of C++11 features that are not supported by MSVC 2012.
>> Is there an existing policy on how supported compiler versions are selected?
> There was a discussion last year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html>) WRT allowing LLVM to use C++11 features which established a precedent of supporting compilers released back for two years, with a special caveat for Windows.
> From the link:
> we support building with the most recent 2 versions of VS available at the *prior* release. For example when we branch for 3.4, the two versions will be 2012 and 2013. Those two would be supported on mainline from then through 3.5, and when we branch for 3.5 we would re-evaluate.
> If that is followed exactly support for VS2012 would not be able to be dropped. However, it is rather easy to get the latest VC++ compiler from Microsoft at no cost (Express edition anybody?), so I don't have any real concern with dropping support for VS2012.
Also from that link:
One short term caveat: Windows is special.
I don't think we should follow the 2-year rule for Windows. It really is
special for at least three reasons:
1) We can't bootstrap on Windows. While there is tons of exciting work
going on here to change that, even then the quality of Windows support is
likely to change very rapidly.
2) Visual Studio's C++ support moved very slowly for a long time, and is
now improving at an amazing rate. We shouldn't be hampered by past problems
and should take advantage of this recent progress.
3) We have less insight into when new versions of the MSVC++ toolchain
I feel it is also worth recognizing that by the time we branch for 3.6 the two most recent versions of Visual Studio will probably be 2013 and 14, so we’re really only proposing moving forward a few months early.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev