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

[Tom Stellard]

On Wed, Nov 06, 2013 at 11:23:35AM -0800, Renato Golin wrote:
> 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.
> 

I would be interested in discussing this at the hacking session.

-Tom