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

Zachary Turner via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 7 12:18:47 PDT 2016


Can you elaborate on the abi incompatibility? I thought there were no
breaks
On Wed, Sep 7, 2016 at 7:59 AM James Molloy via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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
>
> _______________________________________________
> 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/55a484d7/attachment.html>


More information about the llvm-dev mailing list