INN test suite

Russ Allbery rra at stanford.edu
Sat May 23 04:04:51 UTC 2009


Julien ÉLIE <julien at trigofacile.com> writes:

> Should we update the test suite to use your first release of C TAP
> Harness?  (or maybe do you prefer to do it)
>
>    http://www.eyrie.org/~eagle/software/c-tap-harness/

I was going to send a note about that, but hadn't had a chance.

Upgrading runtests.c is trivial since it should be backward-compatible.
However, the most interesting part would be to upgrade libtest.c to the
new TAP library and move the repeated test code in the shell scripts to
the new TAP shell library.

The API is significantly different, though.  Among other things, it
keeps track of the test number internally and instead each test is
tagged with a brief text explanation.  This makes it *way* easier to
find the failing test, but it means every test case has to be changed,
fairly significantly in some cases.

A lot of the tests are for the portability and utility layer, and for
those there are (sometimes slightly improved) versions in rra-c-util:

    http://www.eyrie.org/~eagle/software/rra-c-util/

that also have an updated test suite.  However, rra-c-util has diverged
a fair bit from where it started as part of libinn, and in particular it
now separates the utility library from the portability code and is
designed for projects that use Automake and non-recursive make.  I've
switched all of my projects over to that, but I'm not sure if people are
ready for doing so with INN.  It would mean making it somewhat harder to
build individual directories, and it will make the build process
somewhat slower (Automake isn't the fastest program in the world, not
does it generate the fastest Makefiles).  However, I've found it does
save time over hand-maintained Makefiles.

It would also mean always using libtool rather than making it optional.
I originally made it optional since it was so incredibly slow.  I think
systems have gotten faster (although libtool itself hasn't really), so
this may not be a problem any more, or it may be a tradeoff that's worth
it.

I'm not sure how much time I'd have to help with the work, although I
find it interesting.  I have a bunch of other software releases that I
need to work on over the next month or so, and alas INN isn't something
I get to spend time on as part of my day job and Debian has been eating
up most of the rest of my time.  But I do think in the long run
overhauling the build system and being able to import rra-c-util would
save some time, since I have been enhancing the utility functions over
time and will keep doing so for other projects.  At some point, I'll
suck in the buffer code and work on that as well, since I need it for
another project.  I may come up with a generic version of innd channels
too, since it would solve a problem for a chatserver that I need to do a
real public release of.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.



More information about the inn-workers mailing list