[cfe-dev] Proposal: Managing ABI changes in libc++

C Bergström cbergstrom at pathscale.com
Fri Dec 19 14:24:32 PST 2014


On Sat, Dec 20, 2014 at 4:14 AM, Eric Fiselier <eric at efcs.ca> wrote:
>
> I don't really like allowing users to pick and choose which ABI
> changes to adopt. I personally don't see the use case for picking a
> subset of ABI changes to adopt. If you can adopt one ABI change,
> then why can't you adopt them all? Furthermore, as time goes on and
> more ABI changes are commited this could lead to quite a mess.
>
> I also don't like having a stable version and an unstable version of
> the ABI. I'm afraid that by only introducing ABI changes into the
> "unstable ABI configuration" they will never be adopted.
>
> Instead I think we should version the ABI and introduce a series of
> stable ABI's under different versions. This allows us some sort of
> forward momentum and fewer configurations that need maintaining and
> testing.
> When a consumer can tolerate introducing an ABI break they can move to
> the most recent ABI version. After a given amount of time ABI versions
> would be deprecated.
> The only ABI versions that would be maintained indefinitely would be
> the current one.
>

This idea of ABI "version" paradigms well with real world packages. At some
point we'll in theory have many libc++ packaged and released. If at the
same time of the ABI breakage the libc++.so.${N} is incremented we have
some tangible way to relay that information to potential end users.

I'm personally against the #if hell which could result in multiple
universes (I'd rather put a "stable" piece of code in a maintenance branch,
but that's must my not-so-humble opinion.) It's like saying that the IR
should be stable and never change... This is more user facing and gets more
hand waiving, but at the end of the day it's the same sort of problem.

Every time a set of ABI breaking changes happen.. bump the lib version, cut
a branch before the changes and move on with life... what's so wrong about
this? Changes can be ported forward/backward to the branch as the owners
want. Keep code complexity down..

Further - how do you QA libc++ when there's basically "2" correct ways to
build it? Have the buildbots build it twice and report both results?

For anyone who wants or demands stability.. I'd love to hear why a branch
won't work..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141220/1bc6b968/attachment.html>


More information about the cfe-dev mailing list