Support building without libevent #7339

Closed
wants to merge 6 commits into
from

Projects

None yet

4 participants

@luke-jr
Member
luke-jr commented Jan 13, 2016

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

luke-jr added some commits Dec 25, 2014
@luke-jr luke-jr configure: Make it possible to build only one of bitcoin-cli or bitco…
…in-tx
2b66034
@luke-jr luke-jr Merge branch 'separate_utils-0.10.x' into separate_utils aca0433
@luke-jr luke-jr Merge branch 'separate_utils-0.11.x' into separate_utils b81ce0b
@luke-jr luke-jr 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).
6aed5e6
@jonasschnelli jonasschnelli commented on the diff Jan 14, 2016
configure.ac
@@ -742,6 +759,77 @@ else
fi
fi
+dnl libevent check
@luke-jr
luke-jr Jan 14, 2016 Member

Probably, but IMO outside the scope of this PR.

@jonasschnelli
Member

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
Member
luke-jr commented Jan 14, 2016

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
Member
laanwj commented Jan 18, 2016

Ping @theuni

@laanwj
Member
laanwj commented Jan 27, 2016

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
Member
luke-jr commented Jan 28, 2016

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
Member
laanwj commented Feb 1, 2016

The code changes look OK to me

@laanwj
Member
laanwj commented Feb 3, 2016

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 laanwj closed this Feb 3, 2016
@luke-jr
Member
luke-jr commented Mar 1, 2016

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

@jtimon
Contributor
jtimon commented Mar 1, 2016

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
Member
luke-jr commented Sep 4, 2016

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
Contributor
jtimon commented Sep 7, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment