Support building without libevent #7339

pull luke-jr wants to merge 6 commits into bitcoin:master from luke-jr:opt_libevent changing 6 files +161 −42

luke-jr commented at 11:24 PM on January 13, 2016: member

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).
configure: Make it possible to build only one of bitcoin-cli or bitcoin-tx 2b66034f19
Merge branch 'separate_utils-0.10.x' into separate_utils aca0433e41
Merge branch 'separate_utils-0.11.x' into separate_utils b81ce0bb10

Support building without libevent

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).

6aed5e66ae

luke-jr force-pushed on Jan 13, 2016
in configure.ac:None in d6275ae821 outdated
```
 758 | @@ -742,6 +759,77 @@ else
 759 |    fi
 760 |  fi
 761 |  
 762 | +dnl libevent check
```
jonasschnelli commented at 8:24 AM on January 14, 2016:

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 commented at 3:31 PM on January 14, 2016:

Probably, but IMO outside the scope of this PR.
jonasschnelli commented at 8:29 AM on January 14, 2016: contributor
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.
jonasschnelli added the label Build system on Jan 14, 2016
luke-jr commented at 3:34 PM on January 14, 2016: member
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.
doc: Move libevent from required to optional 78b6762209
luke-jr force-pushed on Jan 15, 2016
laanwj commented at 11:00 AM on January 18, 2016: member

Ping @theuni
Bugfix: Work with explicit --enable-utils f1f73e93a4
laanwj commented at 10:29 AM on January 27, 2016: member

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 commented at 5:34 AM on January 28, 2016: member

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 commented at 1:53 PM on February 1, 2016: member

The code changes look OK to me
laanwj commented at 12:30 PM on February 3, 2016: member

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)
laanwj closed this on Feb 3, 2016
luke-jr commented at 3:59 PM on March 1, 2016: member

Please reopen this. It occurs to me that libbitcoinconsensus and bitcoin-tx will never need libevent.
jtimon commented at 4:23 PM on March 1, 2016: contributor

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 commented at 4:38 PM on September 4, 2016: member

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 commented at 8:07 PM on September 7, 2016: contributor

Sorry for the previous comment. It was not relevant to this PR at all. Please ignore it for this PR.
MarcoFalke locked this on Sep 8, 2021

Contributors

Labels