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

[Rusty Russell]

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.

If you think of CCAN as a separate project, the question becomes: should
we help CCAN, or just do our own samba-specific code?

Obviously, I'd like to help CCAN, since it's my project, but not if it's
too much hassle for SAMBA.

> The issue is that ccan isn't a real library (see above) and
> duplicates our other efforts. If these functions are just included for
> the sake of ntdb, can we perhaps just embed the ones we need
> (privately) in ntdb?

I thought about this, but I think you overestimate the duplication.
The trivial stuff is duplicated, but it's also low-benefit.

OTOH, I'd like SAMBA to unify on ccan/likely and ccan/time; the former
because it has nice infrastructure for measuring branches which
CCAN_LIKELY_DEBUG is set, and the latter because Samba doesn't have a
unified time infrastructure; there are pieces all over the tree.

I think ccan/build_assert and ccan/cast would also be minor wins.

It makes sense also to share some of samba-util with others, by turning
them into CCAN modules, eg. dlinklist.

> ccan also has its own test infrastructure, which means custom code to
> run the ccan and tdb tests, and no integration with the test reporting
> in "make test" or the build farm.

Well, ccan and tdb2/ntdb share the same test infrastructure.  I'd
actually like to make that more common: having infrastructure for
such low-level unit tests in Samba would be a significant benefit.

Cheers,
Rusty.