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/

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

$ make V=1 # will temporarily disable them

otherwise you see:

   CC foo.c

rather than the giant long bulid line.

This makes it significantly easier to spot compiler warnings etc.

Additionally, make them conditional, so we won't error on automake <
1.11

(commits squashed by nickm.)

First, specify -Werror when we are testing each option; if it causes
a warning to appear, we shouldn't be adding it.

Second, do not attempt to add these options until after we have
found the libraries we want.  Previously, I would hit a bug where
the linker hardening options worked fine when we weren't linking
anything, but failed completely once we added openssl or libevent.

Apparently, freebsd 4 doesn't like malloc.h, needs sys/param.h for
MIN/MAX, and doesn't have a SIZE_MAX.

For bug 3894.

This tells the windows headers to give us definitions that didn't
exist before XP -- like the ones that we need for IPv6 support.

See bug #5861.  We didn't run into this issue with mingw, since
mingw doesn't respect _WIN32_WINNT as well as it should for some of
its definitions.

We started adding it in 59e2c778 back in 2004, 8 years and 3
days ago.  It's time to deprogram ourselves from this cargo cult.

This is a matter of making gcc and friends squirm more loudly when
they get an option they don't like (-pedantic) and making clang shut
up with it gets an option it tolerates but doesnt know
(-Qunknown-argument).

Is there no better way?

Also, make the check for whether they're on by default work; there's
no need to mess around with this "$enableval" silliness.

I think that the trailing __ got added in false analogy to
HAVE_MACRO__func__, HAVE_MACRO__FUNC__, and HAVE_MACRO__FUNCTION__.
But those macros actually indicate the presence of __func__,
__FUNC__, and __FUNCTION__ respectively.  The __ at the end of
HAVE_EXTERN_ENVIRON_DECLARED would only be appropriate if the
environ were declared__, whatever that means.

(As a side-note, HAVE_MACRO__func__ and so on should probably be
renamed HAVE_MACRO___func__ and so on.  But that can wait.)

This is an identifier renaming only.

We'd had our configure.in test include unistd.h unconditionally,
which would fail on Windows/mingw, even though environ _was_
declared there.  Fix for 5704; bugfix on 0.2.3.13-alpha.

Thanks to Erinn for finding this and rransom for figuring out the
problem.

Anthony G. Basile authored 13 years ago and Nick Mathewson committed 12 years ago

The bump from miniupnpc-1.5 to 1.6 changes the definition of
two functions used by tor-fw-helper-upnp.c, upnpDiscover() and
UPNP_AddPortMapping().  This patch addresses this and adds a
check in configure.in for backwards compatibility.

Thanks to Nickolay Kolchin-Semyonov for some hints.

X-Tor-Bug-URL: https://trac.torproject.org/projects/tor/ticket/5434
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=376621


Signed-off-by: Anthony G. Basile <blueness@gentoo.org>

This would cause a redundant redeclaration warning on some versions of
Linux otherwise.

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

OS X would otherwise crash with a segfault when linked statically to
some libraries.

Previously we'd been using "we have clock_gettime()" as a proxy for
"we need -lrt to link a static libevent".  But that's not really
accurate: we should only add -lrt if searching for clock_gettime
function adds -lrt to our libraries.

There was one MS_WINDOWS that remained because it wasn't on a macro
line; a few remaining uses (and the definition!) in configure.in;
and a now-nonsensical stanza of eventdns_tor.h that previously
defined 'WIN32' if it didn't exist.

This option seems to be supported all the way back to at least 10.4, so
enabling it for OS X in general should be fine. If not, someone will
yell.

With no libs statically linked, that's a 3% win in binary size, with
just libevent linked statically, this gives us an advantage of 5% in
terms of binary size, and with libevent and openssl statically linked,
we gain over 18% or over 500KB.

Implements ticket 2915.

Fixes bug 4829; bug not in any released tor.