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

On Thu, Sep 1, 2016 at 12:53 PM, Mehdi Amini via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
> Isn’t a big (the most) reason for supporting “old” toolchains to allow
> downstream users to upgrade with some flexibility?
> If I have a large codebase that is using LLVM (let say a few custom
> backends), and is validated with “MSVC 2013”, I can upgrade to “2015” but I
> will need some qualification/validation: this is not free and take some
> time. If you drop aggressively supports for “old” toolchain it means that
> I’m either stuck with an “old” LLVM or that I have to update earlier than
> expected.
>
> Isn’t this usually balanced in upstream LLVM to upgrade when there is a
> real *benefit* to it?
> I’m mentioning it because it seems to conflict with the "always
upgrade to
> the newest one unless there are serious issues with it” you mentioned
above.
>
I agree, we should raise the minimum VS version requirement when the
benefits to the LLVM community outweigh the costs of switching for major
LLVM contributors and users. I think we'll always make that decision in the
same way: by raising it on the mailing lists and discussing the pros and
cons. That's basically what David said when he kicked this whole discussion
off, anyway:

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

I think everything is working as intended here. We raised the VS 2013
upgrade issue, discussed it, determined that it was holding us back, and
now we're doing the upgrade. If VS "15" brings major language
compatibility
improvements, I imagine we'll be having this same discussion again next
year. If it doesn't, and supporting 2015 and "15" at the same time
has the
same cost, then we won't bother raising the floor for a while.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160901/21510e3e/attachment.html>

> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Thu, Sep 1, 2016 at 12:53 PM, Mehdi Amini via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Isn’t a big (the most) reason for supporting “old” toolchains to allow
downstream users to upgrade with some flexibility?
> If I have a large codebase that is using LLVM (let say a few custom
backends), and is validated with “MSVC 2013”, I can upgrade to “2015” but I will
need some qualification/validation: this is not free and take some time. If you
drop aggressively supports for “old” toolchain it means that I’m either stuck
with an “old” LLVM or that I have to update earlier than expected.
> 
> Isn’t this usually balanced in upstream LLVM to upgrade when there is a
real *benefit* to it?
> I’m mentioning it because it seems to conflict with the "always
upgrade to the newest one unless there are serious issues with it” you mentioned
above.
> 
> I agree, we should raise the minimum VS version requirement when the
benefits to the LLVM community outweigh the costs of switching for major LLVM
contributors and users. I think we'll always make that decision in the same
way: by raising it on the mailing lists and discussing the pros and cons.
That's basically what David said when he kicked this whole discussion off,
anyway:
> 
> """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."""
> 
> I think everything is working as intended here.
Right, to be clear there is no misunderstanding: I was absolutely not suggesting
the opposite when answering Zach..

— 
Mehdi

> We raised the VS 2013 upgrade issue, discussed it, determined that it was
holding us back, and now we're doing the upgrade. If VS "15"
brings major language compatibility improvements, I imagine we'll be having
this same discussion again next year. If it doesn't, and supporting 2015 and
"15" at the same time has the same cost, then we won't bother
raising the floor for a while.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160901/97c0e016/attachment.html>

Hi all,

Firstly sorry I'm a bit late responding on this one. Internally to ARM we
build LLVM for Windows. Our current build cluster has only VS2013 installed
and as a result of this thread we've been working on getting VS2015
installed. This involves a certain amount of IT-wrangling as the cluster we
use is company-wide. There have been some hiccups regarding licensing of
MSVC professional (we can't use the community edition for the same reasons
mentioned by Paul previously) but we hoped to be ready in time for the 15th
September switchover date.

It's recently been realised that VS2013 and VS2015 are not ABI compatible
(something that really surprised me), and this means we have to synchronize
moving LLVM's build to VS2015 as well as upgrading a third party library
that we receive from the vendor in compiled library form. This is not
something we're capable of doing by September 15th.

We try really hard at ARM to hide our internal processes because we believe
that they're on the whole irrelevant to the community, however in this case
we'd be really stuck, unable to get production builds.

As this is an ABI-incompatible upgrade, and it's changing the informal
policy on upgrades, could we please have some more grace time? Ideally
another month, so the 15th October. If we haven't sorted it by then,
it's
our problem.

Cheers,

James

On Thu, 1 Sep 2016 at 21:06 Mehdi Amini via cfe-dev <cfe-dev at
lists.llvm.org>
wrote:
> On Sep 1, 2016, at 1:05 PM, Reid Kleckner <rnk at google.com> wrote:
>
> On Thu, Sep 1, 2016 at 12:53 PM, Mehdi Amini via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>>
>> Isn’t a big (the most) reason for supporting “old” toolchains to allow
>> downstream users to upgrade with some flexibility?
>> If I have a large codebase that is using LLVM (let say a few custom
>> backends), and is validated with “MSVC 2013”, I can upgrade to “2015”
but I
>> will need some qualification/validation: this is not free and take some
>> time. If you drop aggressively supports for “old” toolchain it means
that
>> I’m either stuck with an “old” LLVM or that I have to update earlier
than
>> expected.
>>
>> Isn’t this usually balanced in upstream LLVM to upgrade when there is a
>> real *benefit* to it?
>> I’m mentioning it because it seems to conflict with the "always
upgrade
>> to the newest one unless there are serious issues with it” you
mentioned
>> above.
>>
>
> I agree, we should raise the minimum VS version requirement when the
> benefits to the LLVM community outweigh the costs of switching for major
> LLVM contributors and users. I think we'll always make that decision in
the
> same way: by raising it on the mailing lists and discussing the pros and
> cons. That's basically what David said when he kicked this whole
discussion
> off, anyway:
>
> """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."""
>
> I think everything is working as intended here.
>
>
> Right, to be clear there is no misunderstanding: I was absolutely not
> suggesting the opposite when answering Zach..
>
> —
> Mehdi
>
>
> We raised the VS 2013 upgrade issue, discussed it, determined that it was
> holding us back, and now we're doing the upgrade. If VS "15"
brings major
> language compatibility improvements, I imagine we'll be having this
same
> discussion again next year. If it doesn't, and supporting 2015 and
"15" at
> the same time has the same cost, then we won't bother raising the floor
for
> a while.
>
>
> _______________________________________________
> 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/20160907/78a8a9cd/attachment-0001.html>