Apparently "make distcheck" has been broken for 3 months;
I find that hard to believe, but that's what it looks like.
Signed-off-by: Tommi Virtanen <tommi.virtanen@dreamhost.com>
Formerly, we only built gtest when doing 'make check'. However, the
librados-api tests, which are built in debug mode for the 'all' target,
also use gtest. So build it when needed.
Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
An optional argument points can tell it where to put
generated files (in this case, virtualenv). Provide
the argument in Makefile.am.
Options are still passed to cram, so you can say
"./src/test/run-cli-tests -i".
Uses a python package "cram" as test runner.
Requires PIP (python-pip.deb) installed on the
build machine, to actually run these tests.
The cram application itself is included as a
tarball that gets installed in a virtualenv
when the tests are run. cram is GPL.
Use ``make check`` to run the tests.
The src/gtest directory comes from ``svn export
http://googletest.googlecode.com/svn/tags/release-1.5.0 src/gtest``
and running "git add -f src/gtest".
gtest is licensed under the New BSD license, see src/gtest/COPYING.
For more on Google Test, see http://code.google.com/p/googletest/
Changed autogen.sh regenerate gtest automake files too. Make sure to
run ``./autogen.sh && ./configure`` after merging this commit, or
incremental builds may fail. The automake integration is inspired
heavily by the protobuf project, and may still be problematic.
Make git ignore files generated by gtest compilation.
Currently putting in just one new-style unit test, refactoring old
tests to fit will come in separate commits.
Note: if you are starting daemons, listening on TCP ports, using
multiple machines, mounting filesystems, etc, it's not a unit test
and does not belong in this setup. A framework for system/integration
tests will be provided later.
