summaryrefslogtreecommitdiff
path: root/configure.ac
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2013-06-06 14:56:05 -0400
committerNick Mathewson <nickm@torproject.org>2013-07-10 15:20:09 -0400
commitf7d654b81e1a65803c22bb53fc1d3a2021d87d50 (patch)
treef97ef47c02419b0d38f03b85ad62f745e653cf41 /configure.ac
parentfab99844fc324b2c9d415b1b1c192a25cf1c4230 (diff)
downloadtor-f7d654b81e1a65803c22bb53fc1d3a2021d87d50.tar.gz
tor-f7d654b81e1a65803c22bb53fc1d3a2021d87d50.zip
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.
Diffstat (limited to 'configure.ac')
-rw-r--r--configure.ac4
1 files changed, 4 insertions, 0 deletions
diff --git a/configure.ac b/configure.ac
index 235f19b438..34ed524dd8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -39,6 +39,10 @@ AC_ARG_ENABLE(static-tor,
AS_HELP_STRING(--enable-static-tor, Create an entirely static Tor binary. Requires --with-openssl-dir and --with-libevent-dir and --with-zlib-dir))
AC_ARG_ENABLE(curve25519,
AS_HELP_STRING(--disable-curve25519, Build Tor with no curve25519 elliptic-curve crypto support))
+AC_ARG_ENABLE(unittests,
+ AS_HELP_STRING(--disable-unittests, [Don't build unit tests for Tor. Risky!]))
+
+AM_CONDITIONAL(UNITTESTS_ENABLED, test x$unittests != xno)
if test "$enable_static_tor" = "yes"; then
enable_static_libevent="yes";