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

Mihai-Radu, Orza orzamihai at
Thu Jun 21 05:27:09 MDT 2012


I tried building the new samba-4.0.0beta2, but I still get 'err.h: No such file or directory':
[ 553/3679] Compiling lib/tdb/test/external-agent.c
../lib/tdb/test/external-agent.c:7:17: err.h: No such file or directory
Waf: Leaving directory `/tmp/samba-4.0.0beta2/bin'
Build failed:  -> task failed (err #1):
        {task: cc external-agent.c -> external-agent_18.o}
make: *** [all] Error 1

Is there a configure option I can try to get past the error, while the ccan changes are being addressed?


 From: Rusty Russell <rusty at>
To: Jelmer Vernooij <jelmer at> 
Cc: "samba-technical at" <samba-technical at>; Andrew Bartlett <abartlet at> 
Sent: Monday, June 18, 2012 9:50 AM
Subject: Re: code duplication in ccan (was: Re: snprintf on SunOS)
On Sat, 16 Jun 2012 10:28:46 +0200, Jelmer Vernooij <jelmer at> wrote:
> Hi Rusty!

Hi Jelmer,

        In this reply, I've tried to avoid your points which seemed to
be based on your misunderstanding of ccan (corrected in the other
reply), and addressed the rest.

There's some good stuff in here!

> Do we really need 10 files for that in the tree though? I see how it
> would be useful if users grab just one or two modules from the
> website, in this case it's just extra noise.
> Likewise, the _info file uses a format that's completely different
> from the doxygen format that we've standardized on (for better or worse) in the
> rest of Samba.

Well, that's how it is upstream in CCAN.  Is there much point in
diverging for an internal libary?  I've generally avoided that.

> > Specifically smbtorture?  I don't think we can :(
> > We want these lowlevel unit tests to depend on as little as possible,
> > and we want them run first.  Little test programs are nice for that;
> > easy to write, easy to run.
> Not really smbtorture so much as subunit, compatibility with our
> test lists in selftest/ and integration in the test namespace.
> This gives us a uniform way of reporting and analysing test results
> and of running (selected) tests.

That's due to my ignorance :( I thought 'make test' integration was the
right level.

Hmm, there's no selftest/, but I'll poke around and come back
and ask questions if I can't figure out the best way to tie these tests


> I'm not a fan of lots of little C files with simple tests.
> If we would e.g. split up the talloc tests like that we would end up
> with two dozen extra C files; I don't particularly see the advantage
> in that. That's not particularly what I have a problem with here

The separation into files allows them to be trivially independent.  This
allows them to be run in parallel, and individual tests to be run easily
under the debugger.  And it's much easier for a C programmer to write a
C program than understand YA test infrastructure system.

For talloc, there's not much active development, and it's pretty simple.
For tdb, and ntdb, it's not really possible to have them in one binary.

> > I'd like to write more unit tests for Samba code: it's nicer to get a
> > local failure than have smbtorture report some high-level failure
> > halfway through a 2 hour test run :(
> You can run individual tests, there is no need to run the whole thing.

Sorry, I was unclear.  I was referring to the isolation failures, where
a single test run by itself succeeds, but a while 'make test' fails.

This happens occasionally to me, and it's annoying.


More information about the samba-technical mailing list