About Check
-----------

Check is a unit testing framework for C. It features a simple interface
for defining unit tests, putting little in the way of the
developer. Tests are run in a separate address space, so Check can
catch both assertion failures and code errors that cause segmentation
faults or other signals. The output from unit tests can be used within
source code editors and IDEs.

See https://check.sourceforge.net/ for more information, including a
tutorial.  The tutorial is also available as `info check'.

Installation
------------

Check has the following dependencies:

  automake-1.9.6
  autoconf-2.59
  libtool-1.5.22
  pkg-config-0.20
  texinfo-4.7 (for documentation)
  tetex-bin (or any texinfo-compatible TeX installation, for documentation)
  POSIX sed

The versions specified may be higher than those actually needed.

First, do

$ autoreconf --install

in this directory to set everything up.  autoreconf calls all of the
necessary tools for you, like autoconf, automake, autoheader, etc.  If
you ever change something during development, run autoreconf again
(without --install), and it will perform the minimum set of actions
necessary.

Then, read the directions in INSTALL if you need more information.

Linking against Check
---------------------

Check uses variadic macros in check.h, and the strict C90 options for
gcc will complain about this.  In gcc 4.0 and above you can turn this
off explicitly with -Wno-variadic-macros.  In a future API it would be
nice to eliminate these macros.

Debian rationale for not having upstream build packages (.deb files)
--------------------------------------------------------------------

For debian, it is highly undesirable if the upstream source contains a
debian directory as this one will never be the same as the "official"
Debian one, and patching is easier if it's not around.

Sometimes upstream insists on having the possibility to build Debian
packages themselves, in which case it is best to have a debian
directory in the CVS, but not ship it when doing "make dist".

Sometimes upstream insists on shipping the debian directory to their
users so these can easily build a .deb, which is really bad because
they usually don't remmeber to change the Debian changelog and version
accordingly, and generally don't know enough about Debian policy to
make conforming packages.

So in the end you will have different broken packages compiled on
various systems floating around which all have the same version number
and look like offical packages.

  -- Robert Lemmen, 2006

The same holds for .rpm packages.  The Check maintainer for Fedora
Extras, Tom 'spot' Callaway, confirmed that they do not depend on an
upstream rpm target in Check.