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

[Richard Smith]

On Fri, Nov 8, 2013 at 8:49 AM, <dag at cray.com> wrote:

> Chandler Carruth <chandlerc at google.com> writes:
>
> > The overwhelming majority of contributors and users of trunk seem to
> > be fine with this, so while I'm interested in anything we can do to
> > make it easier for you, unless we see significantly more concerns
> > about this plan, I think we should move forward.
> >
> > Fundamentally, we aren't going to be able to make everyone happy. Some
> > people will be seriously inconvenienced by this, but thus far the
> > benefit seems to significantly outweigh the cost.
>
> But the benefit is still there even if it takes a month or two longer.
>
> This is a *serious* issue.  It doesn't seem like people really
> comprehend the challenges of upgrading toolchains in large software
> projects.  We're talking about millions and millions of lines of code
> spread out over many independent modules.  These all have to fit
> together to create a usable tool.
>
> What is so hard about waiting an extra month to give people a chance to
> test the new toolchain?


The options we're discussing seem to be:

1) Switch trunk to C++11 at time T. People whose toolchains aren't ready
stop integrating from LLVM trunk until they are ready.
2) Switch trunk to C++11 at time T + an extra month. Again, people whose
toolchains aren't ready stop integrating from LLVM trunk until they are
ready.

For people who are paying attention to this thread, or to the release
notes, or otherwise being engaged in the community, there seems to be very
little difference. If they do (say) weekly integrates, that's *at most*
three extra integrates they miss. That's unfortunate, but not huge.

For people who are *not* paying attention, this makes no difference at all:
they're not going to start switching their toolchain until they notice a
problem.

So I don't see that waiting is a significant win. Conversely, it gives us
less time to get the C++11-enabled code tested across relevant toolchains
(including perhaps rolling back the change if we find a fatal issue) before
we release 3.5 next year.

Setting T = 3.4 release has another advantage: people who stop integrating
then are stopped at a stable, well-tested revision, not after the
inevitable post-release churn.

> That said, while I'm about to commit the change to the release notes
> > and send a summary email to the dev lists, we should continue
> > discussing this. Nothing is going to be set in stone until the 3.4
> > release goes out, and maybe not even then. Especially if you or others
> > want to discuss this with me in person (or others in person) at the
> > dev meeting, I'm writing this email from the hacking session. =] Happy
> > to chat.
>
> I'm not going to be at the dev meeting.
>
>                          -David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131108/5559af28/attachment.html>