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

Support building without libevent #7339

Closed
wants to merge 6 commits into
base: master
from

Conversation

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

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).
@@ -742,6 +759,77 @@ else
fi
fi
dnl libevent check

This comment has been minimized.

@jonasschnelli
@jonasschnelli

This comment has been minimized.

@luke-jr

luke-jr Jan 14, 2016

Member

Probably, but IMO outside the scope of this PR.

@luke-jr

luke-jr Jan 14, 2016

Member

Probably, but IMO outside the scope of this PR.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jan 14, 2016

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.

Member

jonasschnelli commented Jan 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jan 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.

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

This comment has been minimized.

Show comment
Hide comment
@laanwj
Member

laanwj commented Jan 18, 2016

Ping @theuni

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jan 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.

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

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jan 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.

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

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Feb 1, 2016

Member

The code changes look OK to me

Member

laanwj commented Feb 1, 2016

The code changes look OK to me

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Feb 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)

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

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Mar 1, 2016

Member

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

Member

luke-jr commented Mar 1, 2016

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

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Mar 1, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Sep 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.

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

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Sep 7, 2016

Member

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

Member

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