build: Add warnings for autogen.sh. Fix AC_CONFIG_SRCDIR. #4765

Added warnings and verbosity for autoreconf, should be useful for debugging. AC_CONFIG_SRCDIR argument should actually be a unique file in the src dir, not the dir itself. (http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Input.html) Also moved two AC_CONFIG calls to a more readable (usual) location.

Verbose used to be on, and was only recently disabled: 82ccb05. I don't changing things back and forth, so lets leave it like it is. People that need to debug can always enable verbose.

What's the practice with the warnings=all flag? There are quite a lot of warnings that needs fixing btw.

Showing all warnings seems like a good precaution, unless they're really silly (I haven't tested).

Ok updated. No more verbosity. Warnings on, when they are fixed it will quieten back to standard output (not silly at the moment, imo.)

Mm. I agree with these changes, but they're going to lead to lots of devs scratching their heads and thinking "wtf broke?". See here: https://s3.amazonaws.com/archive.travis-ci.org/jobs/33572253/log.txt and grep for AC_TRY_COMPILE. That's nearly 100 lines of spew that is pretty incomprehensible to anyone but an autotools dev. And every warning but 1 is for deprecated (but working) functions.

I'd say either:

• use --warnings=all,no-obsolete and push this in as-is, then fix the deprecations and remove no-obsolete as a next step or
• fix the deprecated uses in the same PR that turns on the warnings

It seems autoupdate is able to correctly fix the deprecations for me: autoupdate configure.ac src/m4/bitcoin_find_bdb48.m4 src/m4/bitcoin_qt.m4

If you'll add those changes here, ACK.

I've add the fixes for the warnings (which I intended to do in a subsequent PR anyway). Turning off warnings for bad code is not good practice, regardless of which devs are scratching their heads or otherwise, imho.

Does this need to be rebased every day?

@theuni are you OK with this now?

Yes. It'll cause a new warning about the GZIP var, but that's fine. I think we can get rid of that now.

@sipa wasn't aware constant rebase would have any negative downstream implications? Seems like a good practice to keep up-to-date?

The only negative downsides are:

• Prior code review may be invalidated (which seems not very much of an issue here).
• It causes a mail in my mailbox every time (from pulltester) :)

In general, keeping code in sync with the main tree is a good practice imho, but only if you're already changing the code, or it did get unmergable.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4765_e2a98d270d511711111a54f350c25733bc15a5b2/ 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.