Autoconf improvements, part 3 #3242

No description provided.

Tested on OSX 10.9 with homebrew: No more 'No working boost sleep implementation found' error during ./configure Builds fine.

Not internal files and build-targets. What's the benefit? Edit: Whoops, replied in the wrong place. I'm sure you'll find it :p

Makes testing against an alternative LevelDB easier.

Split out bitcoin-cli from bitcoind and rebased.

@luke-jr You missed my point. Please re-read cae63be6c95b19c236a2333c1f2456e016e13f0f. This is not theoretical, it was fixed because it was seen by devs. See here for another explanation: http://stackoverflow.com/questions/17216048/parallel-gnu-make-and-rules-that-create-several-targets-at-once

I really don't like the leveldb changes, -1 to those. The helper libs are becoming a mess as well, I'd like the opportunity to clean those up a bit first before adding more fuel.

@theuni Ugh, that affects multi-target rules too? How annoying. What are your thoughts on the suggestions in that StackOverflow link (a dummy rule that does the real build and depended on by the real targets)?

All you should need to do is to ensure that they're chained:

$(LIBLEVELDB): $(LIBMEMENV)
$(LIBLEVELDB) $(LIBMEMENV): [@echo](/bitcoin-bitcoin/contributor/echo/)...

But this is a good example of why these targets need to be handled in makefiles and not in configure. How 'bout we compromise by setting the path there instead?

(untested)

# if x$enable_external_leveldb != xno; then
#  AC_CHECK_LIB([leveldb])
#  AC_CHECK_LIB([memenv])
#  use_external_leveldb=yes
# fi
# ...
# AM_CONDITIONAL([EXTERNAL_LEVELDB],[test x$use_external_leveldb = xyes])

$(LIBLEVELDB): $(LIBMEMENV)
$(LIBLEVELDB) $(LIBMEMENV): [@echo](/bitcoin-bitcoin/contributor/echo/) ...

if !EXTERNAL_LEVELDB
LIBLEVELDB=leveldb/libleveldb.a
LIBMEMENV=leveldb/libmemenv.a
bitcoind_LDADD += $(LIBLEVELDB) $(LIBMEMENV)
endif

Once those two things are resolved, I retract my -1. I still don't think the leveldb work is useful/warranted, but afaics it's technically sound and I won't stand in the way of it.

+1 to the rest.

thanks, -1 retracted.

Testing on my Mac with 'git test-sequence upstream/master.. 'make clean && make -j 8 check' I got a weird failure on one of the commits:

rm -f libmemenv.a
rm -f libmemenv.a
/usr/bin/ar -rs libmemenv.a helpers/memenv/memenv.o
ar: creating archive libmemenv.a
/usr/bin/ar -rs libmemenv.a helpers/memenv/memenv.o
ar: creating archive libmemenv.a
/usr/bin/ranlib: archive member: libmemenv.a(memenv.o) size too large (archive member extends past the end of the file)
/usr/bin/ar: internal ranlib command failed

Broke on 8f342eb7cbc2efb64fbc1f3eb0bf411a24dfbf35

Checking out that commit, I get flaky results running 'make check' -- looks to me like a dependency is messed up, and the leveldb .a's are being created while the .o's inside them are not quite cooked. E.g. another run produces:

ar: creating archive libleveldb.a
/usr/bin/ranlib: file: libleveldb.a(env_win.o) has no symbols
/usr/bin/ranlib libbitcoin_server.a
make[1]: *** [check-recursive] Error 1
make: *** [check-recursive] Error 1

@gavinandresen that should've been fixed with the last round of changes. It appears to be the race that I referred to above.

Looks good at untested first glance. --enable-frontends=XXX seems annoyingly complex. That's a taste issue; depends on whether others agree.

Given the recent name changes, I imagine --enable-frontends= will become a list of cli,daemon,gui - maybe that's more tasteful?

Given that the frontends are our code, and not some auxiliary setting that should be buried deeply, I'd still prefer

--enable-cli
--enable-daemon
--enable-gui

Rebased and refactored for --enable-gui/cli/daemon per @jgarzik and @laanwj request.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/2041365c8c2d0f8e83715b2a643c3fd2cf6eb4cb for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

Code changes look good to me, going to test this with the various gitian builds.

Works for me (TM)