INN test suite

Russ Allbery rra at stanford.edu
Fri Jan 28 22:07:26 UTC 2011


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

> I also saw that all our tests need being rewritten, as you said, because
> the syntax has totally changed.  Well, for the time being, I have just
> added a wrapper to the new functions; it allows to go on using the
> legacy syntax for the test suite.  Waiting for an upgrade step by step.

> A variable named LIBTEST_NEW_FORMAT can be set at the beginning
> of a test so as to use the new syntax.

That sounds like a very good approach.

One of the things that I've been kicking around for a while is whether I
should see about switching INN to use the infrastructure that I use for my
other projects now.  It was originally built on INN's infrastructure, so
it's familiar, but it's evolved a lot since then.  This would mean
updating portability code from rra-c-util, which among other things would
mean breaking the portability code into a separate directory and library
from libinn.

The biggest hurdle there is that all the infrastructure is now designed
for use with Automake and specifically with Automake with non-recursive
make.  I always build the whole project from the top level with no
Makefiles in individual source directories.  I'm not sure if that would
bother people for INN.  You can still build individual programs because
the programs are separate targets, but you can't do the equivalent of
running make in the frontends directory using that sort of build system.
But it means no longer having to maintain hand-written Makefiles; the top
level Makefile.am is a lot simpler due to Automake's facilities.

I'd probably also advocate simplifying things by removing the build-time
pluggability from overview, storage, and history in favor of requiring
that people who drop in new backends also update Makefile.am.  I don't
think the build-time pluggability has ever really been used, and it
complicates the build system and makes it hard to do non-recursive make.

With those build system changes, it would be very easy to import things
from rra-c-util, and there are some additional portability bits that might
be of interest.  There are also slightly newer versions of things like
messages.c, xmalloc.c, and so forth.

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