code duplication in ccan (was: Re: snprintf on SunOS)

[Jelmer Vernooij]

On Thu, Jun 14, 2012 at 06:57:30PM -0400, simo wrote:
> On Fri, 2012-06-15 at 00:36 +0200, Jelmer Vernooij wrote: 
> > On Sun, Jun 10, 2012 at 01:02:50PM +0930, Rusty Russell wrote:
> > > On Sat, 9 Jun 2012 01:18:29 +0200, Jelmer Vernooij <jelmer at samba.org> wrote:
> > > > We can deprecate functionality from samba-util, but we'll still end up
> > > > with the same issue - two libraries that do essentially the same
> > > > thing.

> > > > In addition, ccan has a modular nature that makes sense for embedded
> > > > projects but not really for Samba, since we're just building it as a
> > > > library anyway. The library can't be public since it doesn't have a
> > > > public ABI (modules can be excluded). Exporting each of the ccan
> > > > modules as a shared library doesn't really make sense, as they're so
> > > > small.
> > > Why don't we just roll ccan into samba-util?  Either move ccan/ under
> > > util, or leave it where it is and just make samba-util pull in ccan.
> > That seems reasonable. We would have to make sure samba-util builds
> > without the rest of Samba so it can be a dependency of tdb, but that's
> > doable (can we name it libtutil?).

> I am really oppoe to make samba-util a dependency for tdb, samba util is
> in NO shape to become a real public library. Let's not do the worst
> thing we could please.

I wasn't saying anything about making it public. ccan already *is* a
dependency of tdb and it's not public either. Neither is a great
situation.

It would be nice to make samba-util public, but that would (as you
said earlier) require some effort to clean it up and define a
stable API.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120615/db61bb0e/attachment.pgp>