-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Support building without libevent #7339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would using a m4 marco make sense here. Something like https://github.com/digitalbitbox/dbb-app/blob/master/build-aux/m4/ax_libevent.m4?
There was a problem hiding this comment.
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.
|
Concept ACK. IMO the only use cases that makes sense:
Not sure if building bitcoind without a RPC server results in something people could use. |
Right now, this PR has the following behaviour:
It is the typical case for at least Gentoo users. |
|
Ping @theuni |
|
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. |
|
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. |
|
The code changes look OK to me |
|
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. |
|
Please reopen this. It occurs to me that libbitcoinconsensus and bitcoin-tx will never need libevent. |
|
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. |
|
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. |
|
Sorry for the previous comment. It was not relevant to this PR at all. Please ignore it for this PR. |
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).