[cfe-dev] How to package library TSes

[Ted Kremenek]

> On Jul 22, 2015, at 8:38 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
> 
> On Wed, Jul 22, 2015 at 1:55 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
> Hi Marshall,
> 
> For some background: We ship libc++ in both the base system and in ports.  Some things use the version in ports, but we expect it to be a drop-in replacement (i.e. if something links libc++ and works with the one in base, then it must also work with the one in ports).  Mostly the one in ports is used by things that require C++14 on systems that ship a libc++ that’s C++11-only.
> 
> OK - thanks for the background.
>  
> If we’re going to ship them in the FreeBSD base system at all, then we need to be able to guarantee ABI (and API) compatibility over the lifetime of a FreeBSD release (5 years).  This means that we’d want to make sure, at the very least, they they’re in versioned namespaces and that people can opt in to newer ones if they want, but still have the older ones available.
> 
> Yeah, I can't do that for the TSes.
> 
> They're "experimental". That means that they can (and will) change - and the changes are not under my control. 
> 
> I (and the others who work on libc++) try very hard to maintain ABI compatibility for the things in the standard; and I think we do a pretty good job. But it's a fair amount of work, and I don't want to take on the burden of doing that for stuff that the committee has declared as "not final".
> 
> That's one of the reasons that I started this email thread - to figure out a good way to hand this.
> 
> 
> -- Marshall
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

I just noticed this thread, so I apologize for being a little late.

On OS X, we can do something similar to how we are handling the Swift runtime:

- Build the TSes in a separate dylib, and distribute that dylib (with its headers) with the compiler.

- When building an app that uses a TS, embed the dylib for the TS inside the app bundle itself.

- The embedded dylib would need to be ABI compatible with the core libc++ dylib on the host system, but that’s as far as it would need to go.  As the TSes evolve, the dylib would change and the app would need to get rebuilt anyway when it picks up a new compiler.

The major downside of this approach is that it creates an expectation of backwards deployment to earlier OSes, even if the TS makes it into the core libc++ dylib on the host system at a later stage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150727/b8c44e27/attachment.html>