llvm dev - Aug 2014 - [LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk

On Thu, Aug 21, 2014 at 7:35 PM, Chris Bieneman <beanz at apple.com>
wrote:
> This thread hasn’t had too much traffic, but it sounds like many people are
> in favor and there is no strong opposition. If I understand Aaron’s only
> objection was based on preserving existing policy rather than a technical
> reason.
>
> Anyone want to make the official call?
I am still opposed.

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."
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.

~Aaron

I don't mean to imply we should change this on three days notice, but I do
think there seems to be quite a bit of interest and very little opposition. I
think we should at least entertain moving forward sooner than the nebulous
release date of MSVC 14 if nobody is tied to 2012.

-Chris

Sent from my iPad
>> On Aug 21, 2014, at 4:48 PM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>> 
>> On Thu, Aug 21, 2014 at 7:35 PM, Chris Bieneman <beanz at
apple.com> wrote:
>> This thread hasn’t had too much traffic, but it sounds like many people
are
>> in favor and there is no strong opposition. If I understand Aaron’s
only
>> objection was based on preserving existing policy rather than a
technical
>> reason.
>> 
>> Anyone want to make the official call?
> 
> I am still opposed.
> 
> 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."
> 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.
> 
> ~Aaron

On Thu, Aug 21, 2014 at 4:48 PM, Aaron Ballman <aaron at aaronballman.com>
wrote:
> On Thu, Aug 21, 2014 at 7:35 PM, Chris Bieneman <beanz at apple.com>
wrote:
> > This thread hasn’t had too much traffic, but it sounds like many
people
> are
> > in favor and there is no strong opposition. If I understand Aaron’s
only
> > objection was based on preserving existing policy rather than a
technical
> > reason.
> >
> > Anyone want to make the official call?
>
> I am still opposed.
>
> 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."
> 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.

So:

1) When we had the discussion 9 months ago I specifically called out that
MSVC might be reasonable rev faster than other compilers due to the rapidly
improving feature set. I think that this thread is essentially exploring
the possibility of actually doing that.

2) I actually think the features listed are *very* valuable. If we can move
faster, I think we should. But there is an "if we can" in there.

3) I completely agree about the 3-days thing. This is a good start, and
none have really shouted in objection. That's a good sign, but I would wait
at least until next week so that we have an LLVM weekly post, and digests
etc go out so that you reach an even larger audience. You should also email
cfe-dev and lldb-dev because those projects are very impacted by this
change.

If next week, no one has raised an objection of the form "this would break
my usage of LLVM" or "I can't easily upgrade for N months",
then I think we
should move forward. At that point I think you should commit something to
the CMake build which errors on old versions of MSVC *without* updating
documentation, policy or code. You'll probably have tto revert it and get
some bots updated. Once the build bot fallout is fixed, and that commit
stays in tree for roughly a week without shouting, I think we can update
the documentation.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140821/f85224f5/attachment.html>

On Thu, Aug 21, 2014 at 9:02 PM, Chandler Carruth <chandlerc at
google.com> wrote:
>
> On Thu, Aug 21, 2014 at 4:48 PM, Aaron Ballman <aaron at
aaronballman.com>
> wrote:
>>
>> On Thu, Aug 21, 2014 at 7:35 PM, Chris Bieneman <beanz at
apple.com> wrote:
>> > This thread hasn’t had too much traffic, but it sounds like many
people
>> > are
>> > in favor and there is no strong opposition. If I understand
Aaron’s only
>> > objection was based on preserving existing policy rather than a
>> > technical
>> > reason.
>> >
>> > Anyone want to make the official call?
>>
>> I am still opposed.
>>
>> 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."
>> 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.
>
>
> So:
>
> 1) When we had the discussion 9 months ago I specifically called out that
> MSVC might be reasonable rev faster than other compilers due to the rapidly
> improving feature set. I think that this thread is essentially exploring
the
> possibility of actually doing that.
>
> 2) I actually think the features listed are *very* valuable. If we can move
> faster, I think we should. But there is an "if we can" in there.
>
> 3) I completely agree about the 3-days thing. This is a good start, and
none
> have really shouted in objection. That's a good sign, but I would wait
at
> least until next week so that we have an LLVM weekly post, and digests etc
> go out so that you reach an even larger audience. You should also email
> cfe-dev and lldb-dev because those projects are very impacted by this
> change.
>
> If next week, no one has raised an objection of the form "this would
break
> my usage of LLVM" or "I can't easily upgrade for N
months", then I think we
> should move forward. At that point I think you should commit something to
> the CMake build which errors on old versions of MSVC *without* updating
> documentation, policy or code. You'll probably have tto revert it and
get
> some bots updated. Once the build bot fallout is fixed, and that commit
> stays in tree for roughly a week without shouting, I think we can update
the
> documentation.
That sounds like a reasonable plan to me, thanks!

~Aaron

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.

cheers,
--renato

I'll second this, for example Reanto, VC 2012 had lots of problems with
your last patch but only one problem with VC 2013 which could be easily
fixed (array initialization). VC C++ conformance is rapidly advancing and
VC 2012 is not up to it.

Yaron



2014-08-22 12:49 GMT+03:00 Renato Golin <renato.golin at linaro.org>:
> 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.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/2bda5ee2/attachment.html>

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