Support building without libevent

[luke-jr]

Without libevent, bitcoind and bitcoin-cli cannot be built, and bitcoin-qt no longer supports -server, -rest, or -torcontrol features (although the debug window still works).

[jonasschnelli]

would using a m4 marco make sense here. Something like https://github.com/digitalbitbox/dbb-app/blob/master/build-aux/m4/ax_libevent.m4?

[luke-jr]

Probably, but IMO outside the scope of this PR.

[jonasschnelli]

Concept ACK.

IMO the only use cases that makes sense:

• Building bitcoin-qt without the -server option and therefore without the libevent dependency.

Not sure if building bitcoind without a RPC server results in something people could use.
Building bitcoin-tx without bitcoind is probably an edge case.

[luke-jr]

Not sure if building bitcoind without a RPC server results in something people could use.

Right now, this PR has the following behaviour:

• --without-libevent --enable-daemon: error
• --without-libevent: do not build bitcoind
• --disable-daemon: use libevent if available
• (neither flag): error if libevent is not available

Building bitcoin-tx without bitcoind is probably an edge case.

It is the typical case for at least Gentoo users.

[laanwj]

Ping @theuni

[laanwj]

I just realized: don't forget that work is underway to use libevent for the P2P code. So this would only be a short-lived change.

[luke-jr]

Hmm, good point. I'd still appreciate review on this, even if it doesn't get merged, since I plan to include it in Bitcoin LJR 0.12.

[laanwj]

The code changes look OK to me

[laanwj]

Closing this; sure, you could use it as a temporary measure, but it doesn't make sense for us given @theuni's work in progress.
(eventually this will be a way of building just bitcoin-tx, which is a very much an edge case)

[luke-jr]

Please reopen this. It occurs to me that libbitcoinconsensus and bitcoin-tx will never need libevent.

[jtimon]

Whether libconsensus needs to support concurrency internally or not (like libsecp256k1 doesn't ) is purely a design choice. My preferred choice is that concurrency is implemented by the caller (I highly doubt libbitcoin would use it otherwise, for example ). See #7566 compared to #7575 for what I mean by decoupling libconsensus from concurrency and storage.

[luke-jr]

In addition to libbitcoinconsensus/bitcoin-tx, we've now gone through two major releases where this would have been useful.

@jtimon libevent isn't concurrency; it's networking.

[jtimon]

Sorry for the previous comment. It was not relevant to this PR at all. Please ignore it for this PR.