ccan dependencies seems to break external projects

[Rusty Russell]

On Tue, 21 Feb 2012 20:19:25 -0500, Stephen Gallagher <sgallagh at redhat.com> wrote:
> > If the problem is that (unlike samba-util) it's used by public libraries
> > (ie. tdb2), then we can wean tdb2 off CCAN, copying in the bits we need.
> > It's ugly, but has the benefit of making tdb2 entirely self-contained.
> 
> Yeah, that's the crux of the issue. If I have a project that links
> against some features of CCAN (or links against a system copy of the
> library, if someone opts to maintain it this way for a distribution) and
> I also attempt to link against libtdb, I run the risk of ending up with
> conflicting symbols.

I don't think this is true any more.  I didn't understand the
consequences of the ccan leakage, but now TDB2 is a full-fledged public
library with symbol hiding, there should be no exposure of CCAN symbols
outside.  So the direct issue is fixed...

> It sounds to me like CCAN is less of a library and more of a collection
> of libraries. So in terms of packaging, it might make sense to package
> each module as its own shared library such as libccan_hash. Then we can
> maintain the module versions individually and handle SOname bumps when
> they're necessary for individual modules.

Yes, it's a library in SAMBA only for convenience; it should probably be
changed (in waf at least) to SAMBA_SUBSYSTEM to make this clear.

Versioning is a very blunt instrument: it forces all users to update in
lockstep.  It only realy makes sense for some limited modules which
really do have stable APIs, such as ccan/hash.  For that, we would save
some footprint by only having one copy.

Hope this helps,
Rusty.