[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 11:02, <dag at cray.com> wrote:

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

That's what I meant. ;)


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

So, here we have an even more serious problem. I can only see these options:

1. Ignore releases, everyone works on trunk
  - Changes are gradual
  1.a No API changes
    - No code breakage, we can use compilers as old as Stallman
    - Every platform is covered
    - The toolchain doesn't evolve
  1.b. API changes between each release
    - API changes under our feet, massive work all the time
    - Many API changes can happen at the same time
    - Warning time can be as little as one day
    - The toolchain evolves with time

2. Use stable releases, only core developers work on trunk
  - Changes are big, infrequent
  2.a No API changes
    - No code breakage, we can use compilers as old as Stallman
    - Every platform is covered
    - The toolchain doesn't evolve
  2.b API changes between each release
    - API changes only after *at least* six months notice
    - Massive work to move code, but only twice a year
    - The toolchain evolves with time

In a nutshell, if we want the toolchain to evolve with time, we'll need to
have API changes, and we'll need to update surrounding software to cope
with that. The only difference is if we want to be doing this as our
day-to-day job, or twice a year (or even less than that if you stay on a
release for a while longer). I personally think that it's more manageable
to do that on releases than on trunk (been there, done that, and it sucks).

All projects that depend on GCC do that on a release basis (including
kernels, distros, etc) and they have a massive undertaking on each release
of the toolchain. That includes new errors, new libraries, new options. In
your case it's a little worse, because it'll also change the compiler
you'll have to use on *your* project, and that's not something GCC users
are used to, but it has to happen one day or another.

Given that this is a special case (warnings have been only hints on the
mailing list, it'll change your compiler, we may want to move to releases),
I think we should wait until everyone is on the same page regarding all
these issues. It's already too late to have a BOF at the US meeting, but we
could gather around during the hacking session today (or via IRC) and try
to come up with a plan.

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