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

[dag at cray.com]

Renato Golin <renato.golin at linaro.org> writes:

> 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've been saying that for years.

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

Totally agree.

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

Except that there hasn't been warning at all.  The only "warning" is
that "we're going to upgrade to some new toolchain."  We need to know
*exactly* which toolchain that is so we can test all of our software
against it.  "4.7.x" doesn't help because every point release has new
bugs, new warnings, new errors, etc.

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

I would love to see that happen.

BUT, right now working off a release is painful because of the
integration cost of upgrading to a new release.  APIs totally change,
new bugs have to be tracked down, performance regressions fixed, etc.
Integrating our changes is a lot of work but it's not the only hard
part.  Dealing with all of the upstream changes at once is a massive
undertaking.

Now that we at least have git mirrors I can manage our custom changes
mostly mechanically (it would be easier if git were the official tool).
But I need manual intervention for handle everything else.  That's very
costly.

When I've explained this in the past, the answer was always, "work off
trunk so the changes are gradual."  I have sympathy for that view.  But
that view is based on the assumption that LLVM doesn't have at least API
backward compatibility.  LLVM is a mature product and I don't think it
has that luxury anymore.  In addition to backports to releases, we need
a process to deprecate APIs if we're going to tell people to work off
releases.

                       -David