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

[Marshall Clow]

> On Dec 8, 2014, at 10:25 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
>> On Dec 8, 2014, at 8:40 AM, Renato Golin <renato.golin at linaro.org> wrote:
>> 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.
> 
> My thought here is that if someone wants a subset of the ABI-breaking changes (but not all of them), 
> they can define the _LIBCPP_ABI_* flags individually in their build system.
> 
> Suppose we have:  in <__config>
> 
> #ifdef _LIBCPP_ABI_UNSTABLE
> #define _LIBCPP_ABI_FEATURE1
> #define _LIBCPP_ABI_FEATURE2
> #define _LIBCPP_ABI_FEATURE3
> #define _LIBCPP_ABI_FEATURE4
> #endif
> 
> If someone wanted just FEATURE2 and FEATURE3, they could do:
> 	cmake <blah, blah> -D_LIBCPP_ABI_FEATURE2 -D_LIBCPP_ABI_FEATURE3

This of course assumes that all the ABI-breaking changes are independent.

— MArshall


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141208/834d2866/attachment.html>