| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
|
| |
|
|
|
|
|
| |
097 hasn't seen a new version since 2007; we can drop support too.
This lets us remove our built-in sha256 implementation, and some
checks for old bugs.
|
| | |
|
| |
|
|
|
|
|
| |
We were trying to incorporate all headers in common_sha1.i, not just
the src/common ones.
This is part of bug 6778; fix on 0.2.4.1-alpha
|
| | |
|
| | |
|
| |
|
|
| |
still a bit odd)
|
| | |
|
|
|
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/
|