[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[Renato Golin]

On 6 November 2013 10:15, <dag at cray.com> wrote:

> No.  We need to know which version of the tools to test.  As far as I
> know, a specific version (point release) hasn't been chosen yet.
>
> A toolchain upgrade is a *major* issue for large software projects.  I'm
> all for C++-11.  It's long past due that we use it in LLVM.  However,
> prudence dictates that we allow enough time for testing before swapping
> toolchains out from under people.
>

Davids,

I think there are two main problems here:
 1. People use trunk on side-projects because releases mean very little in
LLVM world
 2. We start adding new stuff as soon as a release is branched, and that
reduces warnings up to a few days

We're all talking about problem 2, when in fact, I think the problem is in
1.

I personally don't think it's feasible to base a product/project on a
moving target. You already have your code that is moving, having its base
moving too is asking for trouble. This is the same as upgrading the GCC
from 4.8 to 4.9 when it comes out on a major distro just because it's shiny.

Why do we do it, then? Because LLVM releases mean very little, and the only
meaningful branch is trunk. This, for me, is the real problem. There was a
thread a while ago talking about backports for stable releases, and it has
been discussed in the Linaro Connect and other satellite meetings that, if
we want to use LLVM as a platform compiler to whatever project/distro we
*must* maintain old releases. After all, GCC doesn't do that just because
it's fun (believe me, it's not!).

But now that we've come all the way trying to introduce a huge change and
hit this wall, what would the solution be? Are we going to press hard and
make the change? I don't think it's a good idea. As much as I want to see
C++11 and beyond in LLVM, I don't want to destroy one of its biggest
strength: its community.

However, Tim's position is important to consider: we've been talking about
this for a long while, but because no one actually set the date, packagers
and side projects just ignored as a problem 'to deal later, when it really
happens'. So, as much as I understand the work that needs to be done by the
side projects, there has been a lot of warning for almost a year (if not
more). Still, I don't think that an issue like that can be forced down just
because there were discussions on the list, we need a proper schedule.

If we end up with a decent release policy (for backports, bugfixes,
critical performance improvements), side projects and distributions would
be able to use that as a base and let trunk be wild and crazy, as it's
meant to be.

Makes sense?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131106/5e7ae37a/attachment.html>