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

50 lines
2.0 KiB
Plaintext
Raw Normal View History

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
bin_PROGRAMS+= src/tools/tor-resolve src/tools/tor-gencert
noinst_PROGRAMS+= src/tools/tor-checkkey
build tor-cov-{resolve,gencert} This allows us to run tor-cov-gencert from chutney for coverage builds.
2015-03-22 04:21:08 +01:00
if COVERAGE_ENABLED
noinst_PROGRAMS+= src/tools/tor-cov-resolve src/tools/tor-cov-gencert
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_tools_tor_resolve_SOURCES = src/tools/tor-resolve.c
src_tools_tor_resolve_LDFLAGS =
src_tools_tor_resolve_LDADD = src/common/libor.a @TOR_LIB_MATH@ @TOR_LIB_WS32@
build tor-cov-{resolve,gencert} This allows us to run tor-cov-gencert from chutney for coverage builds.
2015-03-22 04:21:08 +01:00
if COVERAGE_ENABLED
src_tools_tor_cov_resolve_SOURCES = src/tools/tor-resolve.c
src_tools_tor_cov_resolve_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_CPPFLAGS)
src_tools_tor_cov_resolve_CFLAGS = $(AM_CFLAGS) $(TEST_CFLAGS)
src_tools_tor_cov_resolve_LDADD = src/common/libor-testing.a \
@TOR_LIB_MATH@ @TOR_LIB_WS32@
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_tools_tor_gencert_SOURCES = src/tools/tor-gencert.c
src_tools_tor_gencert_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@
src_tools_tor_gencert_LDADD = src/common/libor.a src/common/libor-crypto.a \
Add the SHA-3 hash functions to common/crypto.h. * DIGEST_SHA3_[256,512] added as supported algorithms, which do exactly what is said on the tin. * test/bench now benchmarks all of the supported digest algorithms, so it's possible to see just how slow SHA-3 is, though the message sizes could probably use tweaking since this is very dependent on the message size vs the SHA-3 rate.
2015-12-18 23:15:01 +01:00
$(LIBKECCAK_TINY) \
build tor-cov-{resolve,gencert} This allows us to run tor-cov-gencert from chutney for coverage builds.
2015-03-22 04:21:08 +01:00
$(LIBDONNA) \
@TOR_LIB_MATH@ @TOR_ZLIB_LIBS@ @TOR_OPENSSL_LIBS@ \
@TOR_LIB_WS32@ @TOR_LIB_GDI@ @CURVE25519_LIBS@
if COVERAGE_ENABLED
src_tools_tor_cov_gencert_SOURCES = src/tools/tor-gencert.c
src_tools_tor_cov_gencert_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_CPPFLAGS)
src_tools_tor_cov_gencert_CFLAGS = $(AM_CFLAGS) $(TEST_CFLAGS)
src_tools_tor_cov_gencert_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@
src_tools_tor_cov_gencert_LDADD = src/common/libor-testing.a \
src/common/libor-crypto-testing.a \
Add the SHA-3 hash functions to common/crypto.h. * DIGEST_SHA3_[256,512] added as supported algorithms, which do exactly what is said on the tin. * test/bench now benchmarks all of the supported digest algorithms, so it's possible to see just how slow SHA-3 is, though the message sizes could probably use tweaking since this is very dependent on the message size vs the SHA-3 rate.
2015-12-18 23:15:01 +01:00
$(LIBKECCAK_TINY) \
build tor-cov-{resolve,gencert} This allows us to run tor-cov-gencert from chutney for coverage builds.
2015-03-22 04:21:08 +01:00
$(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
@TOR_LIB_MATH@ @TOR_ZLIB_LIBS@ @TOR_OPENSSL_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_LIB_WS32@ @TOR_LIB_GDI@ @CURVE25519_LIBS@
build tor-cov-{resolve,gencert} This allows us to run tor-cov-gencert from chutney for coverage builds.
2015-03-22 04:21:08 +01:00
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_tools_tor_checkkey_SOURCES = src/tools/tor-checkkey.c
src_tools_tor_checkkey_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@
src_tools_tor_checkkey_LDADD = src/common/libor.a src/common/libor-crypto.a \
Add the SHA-3 hash functions to common/crypto.h. * DIGEST_SHA3_[256,512] added as supported algorithms, which do exactly what is said on the tin. * test/bench now benchmarks all of the supported digest algorithms, so it's possible to see just how slow SHA-3 is, though the message sizes could probably use tweaking since this is very dependent on the message size vs the SHA-3 rate.
2015-12-18 23:15:01 +01:00
$(LIBKECCAK_TINY) \
build tor-cov-{resolve,gencert} This allows us to run tor-cov-gencert from chutney for coverage builds.
2015-03-22 04:21:08 +01:00
$(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
@TOR_LIB_MATH@ @TOR_ZLIB_LIBS@ @TOR_OPENSSL_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_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
Remove tor-fw-helper code It did a good idea, but the code-quality of libupnpc and libnatpnp is so dodgy that I'm not really comfortable including them alongside Tor proper. Instead, we'll recommend that people do the pure-go reimplementation instead. Closes ticket 13338.
2015-07-14 20:48:22 +02:00
EXTRA_DIST += src/tools/tor-fw-helper/README
Reference in New Issue Copy Permalink