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

[simo]

On Fri, 2012-06-15 at 01:10 +0200, Jelmer Vernooij wrote: 
> 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.

I am sorry, I made the wrong conclusion that you were proposing
releasing libsamba-util as a standalone library.

However I have to say that, although I agree that ccan is a bit of
duplication, I think I am more comfortable shipping ccan snippets
statically linked in libtdb rather than the whole libsamba-util which is
rather big.

> 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.

Yes, and I think merging in ccan bits would be part of the process,
meaning I do not think we should try to just merge ccan snippets in w/o
doing a full rationalization work here, I do not think we stand to gain
anything if we just drop additional code in there w/o cleaning it up.

I wish I had more time and could get on it, I do not think it would be
overly complex, we have come a long way since the initial mess
libsamba-util was. I think a motivated developer could get it in decent
enough shape to make it possible to release it as a foundation library
for samba related code, but it would require some design and
architecture first, and then implementation, making sure stuff gets
split in a set of understandable and coherent headers, and even doing
some refactoring to make it consistent where needed.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>