[LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk

Aaron Ballman aaron at aaronballman.com
Fri Aug 22 05:43:36 PDT 2014


On Fri, Aug 22, 2014 at 5:49 AM, Renato Golin <renato.golin at linaro.org> wrote:
> On 22 August 2014 00:48, Aaron Ballman <aaron at aaronballman.com> wrote:
>> We told the community less than nine months ago (when we made the
>> C++11 switch) that we would support the last two versions of MSVC. Now
>> we're saying "only the latest version, because it has nice things."
>
> I don't see it this way. We need a compiler on all platforms that can
> conform to the same level of the standards. In most platforms, that's
> GCC and Clang, on Windows, that's also MSVC.
>
> The problem here is that Linux and Mac developers will test their code
> on multiple combinations of { Linux, Mac } x { x86, x86_64, ARM,
> AArch64 } and it'll work perfectly, until it reaches Windows and
> breaks because the compiler can't handle it.
>
> Solving this problem is not trivial, and relying on buildbots to tell
> us what's wrong promotes a culture of trial and error that makes it
> impossible to control the source at any level (ex reverting bugged
> commits, or applying them back again).
>
>
>> That would make sense if those nice things were something we couldn't
>> live without, or if there was a long delay for a new release of MSVC.
>> Neither of those things seem to be the case, so I'm not certain why we
>> would change our developer policy on three day's notice.
>
>  We're finding the hard way that it could have been a lot better if
> MSVC 2012 were actually a modern compiler to begin with. We haven't
> changed the minimum requirement anywhere else, and still, it's MSVC
> that is breaking up. That's a clear sign that MSVC 2012 is *not*
> compatible (feature-wise) with all our other minimum requirements.
>
> IIRC, we "accepted" MSVC 2012 as the minimum requirement due to
> pressure, not because we thought it was a good idea and we said it
> would have to move faster than the others because of the sheer lack of
> functionality. Now it's past 3.5 release and 3.6 will probably come
> out in 2015, the sooner we start the move to a more modern MSVC, the
> better it'll be when we actually release 3.6.
>
> I think Chandler's idea to break it now and see how it goes, by
> changing only the make files, is a good one. At least we'll make all
> the problems visible, and will be able to tackle them one by one,
> instead of waiting for some people to chime in, people that haven't
> been involved yet?
>
> I also believe that we need to answer Alex's questions before
> anything. We can't just guess, as we're talking here of a possible
> massive incompatibility problem on millions of software out there (and
> the games we play!!), so that's a critical issue! :)
>
> But other than that, stakeholders should have been doing their
> homework and trying 2013 ever since 9 months ago. It's most definitely
> not 3 days ago.

I agree with everything you've said. Considering how much effort I
personally put in to ensuring people's code works with MSVC, I
understand the pains involved. ;-)

My opposition to this switch was the timing. When we researched "what
minimum can we live with for C++11" nine months ago, we determined
what versions would make sense, which included MSVC 2012, and told
people what the plan was. My concern was pulling the rug out from
under people who were relying on that determination without putting in
the proper research and giving them enough time to react.

All of the reasons for upgrading that have been pointed out are valid
and are opinions I share. At the same time, we've managed to get by
acceptably well for nine months. That is why I spoke up when the
original proposal came in asking to switch without putting forward a
concrete plan. Chandler has laid out a plan that I am really happy
with, and if we don't have any stakeholders who have a reliance on
MSVC 2012, I'm happy to up the minimum to MSVC 2013 because it is a
considerably better toolchain.

~Aaron



More information about the llvm-dev mailing list