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

Rusty Russell rusty at ozlabs.org
Mon Jun 18 00:50:00 MDT 2012


On Sat, 16 Jun 2012 10:28:46 +0200, Jelmer Vernooij <jelmer at samba.org> 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/tests.py 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/tests.py, but I'll poke around and come back
and ask questions if I can't figure out the best way to tie these tests
together!

Thanks!

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

Cheers,
Rusty.


More information about the samba-technical mailing list