nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-11 13:43:47 +01:00
Code Issues Packages Projects Releases Wiki Activity
9d8ffa91ce
tor/src/test/include.am

78 lines
2.4 KiB
Plaintext
Raw Normal View History

fix TESTS to include full path to src/test/test
2012-08-03 01:05:18 +02:00
TESTS+= src/test/test
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
noinst_PROGRAMS+= src/test/bench
if UNITTESTS_ENABLED
noinst_PROGRAMS+= src/test/test src/test/test-child
endif
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src_test_AM_CPPFLAGS = -DSHARE_DATADIR="\"$(datadir)\"" \
-DLOCALSTATEDIR="\"$(localstatedir)\"" \
-DBINDIR="\"$(bindir)\"" \
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
-I"$(top_srcdir)/src/or" -I"$(top_srcdir)/src/ext" \
-DTOR_UNIT_TESTS
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
# -L flags need to go in LDFLAGS. -l flags need to go in LDADD.
# This seems to matter nowhere but on Windows, but I assure you that it
# matters a lot there, and is quite hard to debug if you forget to do it.
src_test_test_SOURCES = \
src/test/test.c \
src/test/test_addr.c \
Refactor begin cell parsing into its own function, with tests. Add 'flags' argument to begin cells, per proposal 208.
2012-10-22 17:28:37 +02:00
src/test/test_cell_formats.c \
Add some basic unit tests for the circuit map data structure. These show off the new mocking code by mocking the circuitmux code so that we can test the circuit map code in isolation.
2013-07-10 21:07:32 +02:00
src/test/test_circuitlist.c \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src/test/test_containers.c \
src/test/test_crypto.c \
Unit tests for cell queues. This removes some INLINE markers from functions that probably didn't need them.
2013-07-18 17:02:36 +02:00
src/test/test_cell_queue.c \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src/test/test_data.c \
src/test/test_dir.c \
src/test/test_introduce.c \
src/test/test_microdesc.c \
Start of a unit test for options_validate. 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.
2013-07-18 20:38:31 +02:00
src/test/test_options.c \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src/test/test_pt.c \
src/test/test_replay.c \
src/test/test_util.c \
src/test/test_config.c \
Move all externally maintained source files into src/ext The rationale for treating these files differently is that we should be checking upstream for changes as applicable, and merging changes upstream as warranted.
2012-10-11 23:19:37 +02:00
src/ext/tinytest.c
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
Coverage support: build with --enable-coverage to have tests run with gcov 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.
2013-07-09 18:37:11 +02:00
src_test_test_CFLAGS = $(AM_CFLAGS) $(TEST_CFLAGS)
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src_test_test_CPPFLAGS= $(src_test_AM_CPPFLAGS)
src_test_bench_SOURCES = \
src/test/bench.c
src_test_bench_CPPFLAGS= $(src_test_AM_CPPFLAGS)
src_test_test_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@ \
@TOR_LDFLAGS_libevent@
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
src_test_test_LDADD = src/or/libtor-testing.a src/common/libor-testing.a \
src/common/libor-crypto-testing.a $(LIBDONNA) \
src/common/libor-event-testing.a \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
@TOR_ZLIB_LIBS@ @TOR_LIB_MATH@ @TOR_LIBEVENT_LIBS@ \
Actually link against nacl when we want to use it Fixes more of bug 7972
2013-01-16 19:07:52 +01:00
@TOR_OPENSSL_LIBS@ @TOR_LIB_WS32@ @TOR_LIB_GDI@ @CURVE25519_LIBS@
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src_test_bench_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@ \
@TOR_LDFLAGS_libevent@
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
src_test_bench_LDADD = src/or/libtor.a src/common/libor.a \
src/common/libor-crypto.a $(LIBDONNA) \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src/common/libor-event.a \
@TOR_ZLIB_LIBS@ @TOR_LIB_MATH@ @TOR_LIBEVENT_LIBS@ \
Actually link against nacl when we want to use it Fixes more of bug 7972
2013-01-16 19:07:52 +01:00
@TOR_OPENSSL_LIBS@ @TOR_LIB_WS32@ @TOR_LIB_GDI@ @CURVE25519_LIBS@
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
noinst_HEADERS+= \
src/test/test.h
Add reference implementation for ntor, plus compatibility test Before I started coding ntor in C, I did another one in Python. Turns out, they interoperate just fine.
2012-12-08 06:52:44 +01:00
if CURVE25519_ENABLED
noinst_PROGRAMS+= src/test/test-ntor-cl
src_test_test_ntor_cl_SOURCES = src/test/test_ntor_cl.c
src_test_test_ntor_cl_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@
src_test_test_ntor_cl_LDADD = src/or/libtor.a src/common/libor.a \
src/common/libor-crypto.a $(LIBDONNA) \
@TOR_ZLIB_LIBS@ @TOR_LIB_MATH@ \
Actually link against nacl when we want to use it Fixes more of bug 7972
2013-01-16 19:07:52 +01:00
@TOR_OPENSSL_LIBS@ @TOR_LIB_WS32@ @TOR_LIB_GDI@ @CURVE25519_LIBS@
Add reference implementation for ntor, plus compatibility test Before I started coding ntor in C, I did another one in Python. Turns out, they interoperate just fine.
2012-12-08 06:52:44 +01:00
src_test_test_ntor_cl_AM_CPPFLAGS = \
-I"$(top_srcdir)/src/or"
endif
Reference in New Issue Copy Permalink