Aaron Ballman
2014-Aug-21 23:48 UTC
[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
Chris Bieneman
2014-Aug-22 00:54 UTC
[LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk
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
Chandler Carruth
2014-Aug-22 01:02 UTC
[LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk
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>
Aaron Ballman
2014-Aug-22 01:29 UTC
[LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk
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
Renato Golin
2014-Aug-22 09:49 UTC
[LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk
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
Yaron Keren
2014-Aug-22 10:42 UTC
[LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk
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>
Aaron Ballman
2014-Aug-22 12:43 UTC
[LLVMdev] [RFC] Raising minimum required Visual Studio version to 2013 for trunk
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