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

[Jelmer Vernooij]

On Sat, Jun 09, 2012 at 05:54:07PM -0400, simo wrote:
> On Sat, 2012-06-09 at 22:16 +0200, Jelmer Vernooij wrote: 
> > On Sat, Jun 09, 2012 at 04:51:51PM +1000, Andrew Bartlett wrote:
> > > On Sat, 2012-06-09 at 01:18 +0200, Jelmer Vernooij wrote:
> > > > On Sat, Jun 09, 2012 at 08:40:51AM +1000, Andrew Bartlett wrote:
> > > > > On Fri, 2012-06-08 at 18:23 +0200, Jelmer Vernooij wrote:
> > > > > > On Thu, Jun 07, 2012 at 02:34:52PM +1000, Andrew Bartlett wrote:
> > > > > > > On Wed, 2012-06-06 at 03:13 -0700, Mihai-Radu, Orza wrote:
> > > > > > > > Thank you for the patch. I managed to go past the asn1 linkage problem, so it helped.

> > > > > > > > But now I get the following build error:
> > > > > > > > [ 522/3534] Compiling lib/ccan/failtest/failtest.c
> > > > > > > > ../lib/ccan/failtest/failtest.c:8:17: err.h: No such file or directory
> > > > > > > > Waf: Leaving directory `/tmp/samba-4.0.0beta1/bin'
> > > > > > > > Build failed:  -> task failed (err #1):
> > > > > > > >         {task: cc failtest.c -> failtest_1.o}

> > > > > > > > The err.h C header does not come with SunOS so I guess the compiler should use the replacement functions defined in source4\heimdal_build\replace.c. Is there some config param I'm missing?

> > > > > > > > Thanks again and regards,
> > > > > > > > Mihai

> > > > > > > In the short term, it seems you should be able to

> > > > > > > rm -rf lib/ccan/failtest

> > > > > > > as this code is unused.  You may have noticed I've mailed the ccan
> > > > > > > maintainer to understand what we are going to use the code for, and how
> > > > > > > to best handle this in the future. 
> > > > > > This is related to something I've been wondering about for a while.
> > > > > > Ccan reinvents the wheel and is separate from lib/util (of which it
> > > > > > duplicates a lot) and has its own test infrastructure. 
> > > > > One problem is that tdb2/ntdb uses ccan (but it uses a lot of it for
> > > > > only for failtest), and is an 'independent' (or at least able to be
> > > > > built as independent) package.  

> > > > > We could deprecate parts of libsamba-util for ccan of course.
> > > > > Presumably the licences also set much the same course (ccan being LGPL
> > > > > or less to build an LGPL tdb2/ntdb).
> > > > We used to have a single library for portability (libreplace), and one
> > > > for common convenience functions (libsamba-util).  ccan adds yet another
> > > > library which overlaps with both of these.
> > > I agree that for Samba's use, the portability aspects of ccan should go
> > > into libreplace.  Indeed, perhaps just as a ccan subdir of libreplace
> > > (if ccan is intended to be copied into projects, why not just copy it
> > > into the right part of our project?).
> > In that case we should be embedding it in libsamba-util; libreplace is aimed at
> > providing replacements for standard functionality on operating systems
> > where it is missing - and so it can be excluded altogether on modern
> > systems. ccan's functionality isn't standard in any way.
> libsamba-util has quit a large footprint and would be a circular
> dependency.
Hence my original suggestion to just include the handful of functions
that we use from ccan directly in tdb. That avoids the trouble of
having to define what the ccan shared library means and what should be
included in it.

Anyway, having ccan as a separate library is a nuisance, but we seem
to have resolved most of the issues around it. I'm more concerned
about the custom test suite.

> We'd need to make it an independently buildable library, probably remove
> all the dyn_* symbols and the debug symbols that should have not have
> been made public in the first place (IMO) and perhaps split it in pieces
> that make sense and can use single coherent header files.

> I am certainly not against such a clean-up, who wants to start ?
Cleaning up the util library and making it externally usable (the
samba equivalent of glib, basically) would be nice too. But I agree it
would also be a lot more work.

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/20120614/d0939e77/attachment.pgp>