Making the text file work out-of-tree didn't work on windows.

Maybe we can get it working that way later.

dana koch authored 10 years ago and Nick Mathewson committed 10 years ago

A new set of unit test cases are provided, as well as introducing
an alternative paradigm and macros to support it. Primarily, each test
case is given its own namespace, in order to isolate tests from each
other. We do this by in the usual fashion, by appending module and
submodule names to our symbols. New macros assist by reducing friction
for this and other tasks, like overriding a function in the global
namespace with one in the current namespace, or declaring integer
variables to assist tracking how many times a mock has been called.

A set of tests for a small-scale module has been included in this
commit, in order to highlight how the paradigm can be used. This
suite gives 100% coverage to status.c in test execution.

Also rename a function to be more accurate (resolve->resolved)

This function is not used anymore

'make distcheck' now passes again.

These need to be a separate executable, since the point of backtrace.c
is that it can crash and write stuff.

I broke this when I added separate test-mode support by having
the benchmarks get built with TEST_CFLAGS.

No other changes were made here.  Keeping everything in
src/test/test.c was a legacy of back when we had all our unit tests in
one big file.

Doing this now because I'm adding an ext_or_command test.

This exercises the code that crashed and caused #9296.

I added this so I could write a unit test for ServerTransportOptions,
but it incidentally exercises the succeed-on-defaults case of
options_validate too.

This removes some INLINE markers from functions that probably didn't
need them.

These show off the new mocking code by mocking the circuitmux code
so that we can test the circuit map code in isolation.

If you pass the --enable-coverage flag on the command line, we build
our testing binaries with appropriate options eo enable coverage
testing.  We also build a "tor-cov" binary that has coverage enabled,
for integration tests.

On recent OSX versions, test coverage only works with clang, not gcc.
So we warn about that.

Also add a contrib/coverage script to actually run gcov with the
appropriate options to generate useful .gcov files.  (Thanks to
automake, the .o files will not have the names that gcov expects to
find.)

Also, remove generated gcda and gcno files on clean.

This is mainly a matter of automake trickery: we build each static
library in two versions now: one with the TOR_UNIT_TESTS macro
defined, and one without.  When TOR_UNIT_TESTS is defined, we can
enable mocking and expose more functions. When it's not defined, we
can lock the binary down more.

The alternatives would be to have alternate build modes: a "testing
configuration" for building the libraries with test support, and a
"production configuration" for building them without.  I don't favor
that approach, since I think it would mean more people runnning
binaries build for testing, or more people not running unit tests.

Fixes more of bug 7972

Before I started coding ntor in C, I did another one in Python.
Turns out, they interoperate just fine.

This lets us give it compiler flags differing from the rest of
libor-crypto.a

Add 'flags' argument to begin cells, per proposal 208.

The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.

Stewart Smith authored 12 years ago and Nick Mathewson committed 12 years ago

This gives us a few benefits:
1) make -j clean all
   this will start working, as it should. It currently doesn't.
2) increased parallel build
   recursive make will max out at number of files in a directory,
   non-recursive make doesn't have such a limitation
3) Removal of duplicate information in make files,
   less error prone

I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way
that was used was not only deprecated but will be *removed* in the next
major automake release (1.13).... so probably best that we can continue
to bulid tor without requiring old automake.
(see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html )

For more reasons  why, see resources such as:
http://miller.emu.id.au/pmiller/books/rmch/