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

Tim Northover <t.p.northover at gmail.com> writes:
>>> If the new feature requires out-of-tree LLVM users to upgrade their
>>> toolchains then we may only be giving them a month or less warning,
>>> even if we are giving downstream packagers 6 months.
>>
>> Correct.  That's not enough warning.
>
> If we decide to delay this yet again (it's been on the cards since
> January, so I'm personally opposed, but still...) we should at least
> start counting the "acceptable notice" from the start of this
thread
> rather than when the dust settles.
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.

                            -David

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>

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

On 11/ 7/13 01:50 AM, Renato Golin wrote:

<snip>
> 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).
warnings are not errors - I think everyone is in agreement this should 
happen or at least not opposed to it from what I've read.

My view and seems to be supported by a (small?) handful of others
Dec 1st == too soon
Jan 15th-Feb 1st == ok (that's my position)
----------
This virtual discussion needs to stop - Things need to move forward. The 
missing pieces in my mind are 2
1) Someone proposes an updated style guide for review
2) Date which ToT becomes open for C++11 hunting