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

[Renato Golin]

Hi Marshall,

I agree this is a good idea...


On 8 December 2014 at 15:42, Marshall Clow <mclow.lists at gmail.com> wrote:
> a) There are the people who ship libc++ in production systems, who say: Whoa! Don’t do that! Ever! (or at least “let us decide when”).
> b) There are the people who use libc++ internally, who say: Is it faster? Does it work better? Do it!

And there are those that accept each one on different occasions. :)


> Concrete steps:
> 1) Give each ABI-breaking change its own "enabling macro”, that starts with “_LIBCPP_ABI_”

This sounds reasonable.


> 2) Create a global macro “_LIBCPP_ABI_UNSTABLE” which, when defined, turns on ALL of the _LIBCPP_ABI_* changes.

While this can be problematic. What if group A wants ABI-breaking
changes X and Y, while group B want Z? In the beginning, we could all
all of them under the same umbrella, but as requests come in, we could
end up with a set of sets, unions and intersections of macros, which
are never pretty. Brainstorming a bit, to avoid intersections and
separate sets, we could make it into a severity scale (like unstable
-> broken -> napalm). But I'm over-engineering, as usual.

Having said that, I think the simple all or nothing will be perfect
for 99% of the cases, so I think this could work very well in
practice. We just have to make sure we test both variations as often
as possible.

cheers,
--renato