[cfe-dev] How to package library TSes

[David Chisnall]

On 23 Jul 2015, at 05:45, Marshall Clow <mclow.lists at gmail.com> wrote:
> 
> On Wed, Jul 22, 2015 at 9:43 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
> On Wed, Jul 22, 2015 at 8:54 PM, Dan Albert <danalbert at google.com> wrote:
> For cases like the base library that do require that kind of absolute compatibility maybe the best solution is to just not include any of the experimental features. If I understand David correctly the one in ports could include the experimental features for the users that want it.
> 
> I think that that could work for FreeBSD.
> 
> 
> Followup - some of the TSes are almost completely implemented in headers, and do not require any changes to the dylib.

With regard to ABI compatibility, there are two issues:

1) Library A uses v1, library B uses v2, program links to library A and library B.

2) Library A uses v1, library B uses v2, library A exposes v1 types at library API boundaries.

I think the second case is not worth considering - if you use experimental features in your public interface, then you expect stuff to break.  The first case would be nice to support though.  As long as any ABI-breaking change has a new namespace version, then we can provide a library that contains the old and new versions.

This is particularly important if the ABI changes are the result of API changes - it’s trivial for us to recompile everything (we rebuild all packages roughly once a day anyway), but it’s much harder to make every third-party package update their API usage (even getting all of the tr1:: users to use the C++11 versions for simple things like unordered_map and unordered_set in libc++ required patching a thousand or so ports, and I’d like to not have to do that again).

If we aim not to ship the experimental stuff in the base system, and have a libc++-experimental.so provided by a port that contains the TS stuff, then that means that we don’t have to *guarantee* ABI stability, but we’re still going to have pain if we aren’t able to support multiple versions of the APIs.

David