Skip to content

Conversation

@luke-jr
Copy link
Member

@luke-jr 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).

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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably, but IMO outside the scope of this PR.

@jonasschnelli
Copy link
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.

@luke-jr
Copy link
Member Author

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
Copy link
Member

laanwj commented Jan 18, 2016

Ping @theuni

@laanwj
Copy link
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
Copy link
Member Author

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
Copy link
Member

laanwj commented Feb 1, 2016

The code changes look OK to me

@laanwj
Copy link
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
Copy link
Member Author

luke-jr commented Mar 1, 2016

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

@jtimon
Copy link
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
Copy link
Member Author

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
Copy link
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.

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants