llvm dev - Aug 2016 - [cfe-dev] Revisiting our informal policy to support two versions of MSVC

-----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Aaron
> Ballman via cfe-dev
> Sent: Tuesday, August 02, 2016 12:06 PM
> To: David Majnemer
> Cc: llvm-dev; cfe-dev
> Subject: Re: [cfe-dev] [llvm-dev] Revisiting our informal policy to
> support two versions of MSVC
> 
> On Tue, Aug 2, 2016 at 1:24 PM, David Majnemer via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hello,
> >
> > Today we hit another VS 2013 breakage
> > <http://lab.llvm.org:8011/builders/sanitizer-
> windows/builds/26666/steps/run%20tests/logs/stdio>
> > which results us having to alter LLVM.
> >
> > While we have no documented policy of supporting two version of MSVC,
we
> do
> > have an informal agreement that we should support the last two
versions.
> >
> > I suggest that we alter our informal policy to the following:
> >
> > "If a compiler version keeps getting in the way and a newer
compiler is
> > available, we should ask people to upgrade to that newer
compiler."
> 
> I think that's reasonable, but I also think this is no different than
> what we already do today, which is unfortunate. The lack of
> predictability of when we drop support for MSVC is something I would
> hope we can address. That's what the "last two versions" was
hoping to
> achieve, but hasn't in practice since we've never actually adhered
to
> that policy due to finding pain points to justify dropping early.
> Since this proposal is basically preserving the status quo, I don't
> think predictability needs to be solved in order to move forward with
> the proposal of dropping support for 2013.
> 
> To me, the goal of having some degree of predictability with compiler
> versions is for people with out-of-tree projects to have a chance of
> knowing when support for a compiler may be dropped and plan
> accordingly. This isn't traditionally a problem with GCC (e.g.)
> because the stability of features and functionality is usually a bit
> higher than with MSVC, where major upgrades can be challenging and
> labor-intensive for some projects.
For my project, timing is everything.  We (and I could easily imagine,
for many downstream projects) lead time is important.  We've just had
a release branch, so making a *decision* right now that we *implement*
in 2-3 months is something we should find tolerable.  (We'd need to do
a bunch of internal validation, then deploy 2015 to all the developers
and all the bots... these things take time.)  I have already brought
this up with my management and we'll need to assign some resources to
it in order to start that evaluation.
> Maybe we can bring back the notion
> of  "last two versions" sometime in the future if MSVC
functionality
> stabilizes a bit more.
You'd have to get the C++ committee to stabilize the language first. :-)
Seriously, MSVC 2013 would be distinctly less of a problem if people
weren't trying to use defaulted move constructors.  I think that's a
fine feature to want to be using, but it wasn't on the list back when
we decided to make 2013 the minimum version.  The developer community's
desired feature set has increased, so it's reasonable to debate moving
the minimum bar on that basis.
> 
> > If we can support ten versions of MSVC with little burden, I don't
see a
> > reason why we shouldn't.
> >
> > But if we find ourselves in a situation where asking folks to upgrade
to
> a
> > compiler which has been widely deployed soothes development for the
> greater
> > LLVM community, we should consider dropping support for the older
> versions
> > of that compiler.
> 
> Totally agreed.
> 
> > In this case, dropping VS2013 allows us to use more C++11 features
with
> > confidence.  Notably, move constructors will be synthesized instead of
> > having to be manually written (and kept in sync with data members
> getting
> > added).
> >
> > What do you all think?  Are folks still stuck on VS2013?
> 
> Assuming that we don't have any major barriers to dropping MSVC 2013,
> I am okay with it.
Same here.  We will need to do our internal validation first, and
I'd bet we aren't the only ones.
--paulr
> Additional request: can we also informally require
> the latest Update to be installed for whatever versions of MSVC we
> support (if we don't already)? I don't see a whole lot of value to
> keeping support for Update 1 & 2 when Update 3 is out.
> 
> ~Aaron
> 
> >
> > Thanks,
> > David
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On Tue, Aug 2, 2016 at 3:49 PM, Robinson, Paul via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> For my project, timing is everything.  We (and I could easily imagine,
> for many downstream projects) lead time is important.
>
In Chromium land, we've so far been able to use the same compiler we use to
build Chrome to build clang. Currently that's MSVS2015 update 2, and it
took quite a while to update from 2013 to 2015 due bugs in 2015 and
whatnot. So I agree that it's useful to support older MSVS versions for
some time. For this reason, requiring update 3 would be inconvenient for
us, but 2015u2 would be no problem by now. It would've been a problem if
2015 had been required shortly after it was released.

Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160802/86ce3403/attachment.html>

Hi,

This sounds like a decent idea to me. However we use 2013 for all our
windows builds at the moment and it will take around 2 weeks to upgrade the
installations on our cluster. We're pushing this hard to get it done soon
so we don't get caught short, but a grace period would be much appreciated.

Cheers,

James

On Tue, 2 Aug 2016 at 21:24 Nico Weber via cfe-dev <cfe-dev at
lists.llvm.org>
wrote:
> On Tue, Aug 2, 2016 at 3:49 PM, Robinson, Paul via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> For my project, timing is everything.  We (and I could easily imagine,
>> for many downstream projects) lead time is important.
>>
>
> In Chromium land, we've so far been able to use the same compiler we
use
> to build Chrome to build clang. Currently that's MSVS2015 update 2, and
it
> took quite a while to update from 2013 to 2015 due bugs in 2015 and
> whatnot. So I agree that it's useful to support older MSVS versions for
> some time. For this reason, requiring update 3 would be inconvenient for
> us, but 2015u2 would be no problem by now. It would've been a problem
if
> 2015 had been required shortly after it was released.
>
> Nico
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160803/11695914/attachment.html>