Stefano Lattarini <stefano.lattar...@gmail.com> writes: > Consider that the whole point of the TAP support in Automake is that the > testsuite harness present in Automake-generated makefiles (the one that > gets launched by "make check") will act as TAP consumer itself. Thus > the "harness" part of Russ' package is likely of little or no use in > conjunction with the newer Automake test harness -- but of course you > can reuse the part of his project that provide a TAP *producer* for C > and/or Shell programs.
Indeed. The purpose of the C TAP Harness project is to provide sort of a toolkit and you can mix and match whatever pieces you want. I personally use the harness included there just because I wrote it and therefore it does everything the way that I like having it done, although at some point I want to look at the TAP support directly in Automake and see if it can now do everything it does. But the libraries are more directly useful to anyone doing something with TAP, and reflect about 10 years of accumulated experience with all the various weird things that one ends up needing to do in a project that also uses Automake. They don't just handle the test stream; there are also functions for handling the special cases that come up in finding supporting test data with srcdir != builddir builds and things along those lines. And the C library takes care of a bunch of annoying bookkeeping for you and provides some wrapper functions around memory allocation that call bail() on failure for clean failure of tests in low-memory conditions. I know of several other people who are using the libraries but just using prove as the test suite driver. Incidentally, for anyone doing a lot with TAP, you may also want to look at the TAP add-ons that are part of my general C utility collection: http://www.eyrie.org/~eagle/software/rra-c-util/ C TAP Harness is developed under a strict requirement that it not need to use Autoconf, so it only uses completely standard C functions. The rra-c-util add-ons are allowed to depend on a broader portability framework (I use mine, but gnulib would presumably work as well) and therefore include TAP add-ons that do things like wrap asprintf() to test for success, to fork a subprocess and check its output, and to run an external program to do setup at the start of a test. (Sometimes it's a lot easier to do your test setup in shell or some other scripting language rather than C, while the core test code has to be written in C because of what it's testing.) -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>