-
Notifications
You must be signed in to change notification settings - Fork 14
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
Organization of Source Code #898
Labels
Milestone
Comments
Circular dependencies in bitcoin master
Circular dependencies in unit-e master ec33ab3:
This has already bitten us while working on merging 0.17. |
Here is the corresponding ticket in bitcoin: bitcoin/bitcoin#15732 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bitcoin-core (and therefore unit-e) is divided into libraries:
libunivalue
libunite_server
libunite_common
libunite_consensus
libunite_util
libunite_crypto
libunite_zmq
libunite_usbdevice
libunite_wallet
libleveldb
,libsecp256k1
, ...)The following executables exist:
unit-e
unit-e-cli
unit-e-tx
test_unite
bench_unite
The dependency graph between them should (it unfortunately does not) look roughly like this:
Source for this graph:
Unfortunately this is not the case. We frequently run into linking issues and even on the source level we have circuler dependencies (use
circular-dependencies.py
).This begs the question of how we should go about resolving this situation. Bitcoin is separating modules more and more, while we have been adding circular dependencies rather carelessly. In fact one of the questions here is: Do we need the separation into these modules?
Circular dependencies are inherently bad. Some examples:
A
includesB
andB
includesA
some compilation problems might only arise if your platform decides to loadA
first ofB
first. For instance: You might have missed a forward declaration inA
to a symbol inB
. By chance your platform (filesystem, compiler) processesB
first. No problem. On somebody else's platform the compiler processesA
first -> compilation error (this has happened to use with standard headers even like#include <functional>
which broke the build on everybody's platform, except in travis or on mac)Some programming languages (Go, Haskell, ...) do not even support circular dependencies between modules, precisely because of the afore mentioned problems. Ciruclar dependencies are hard.
The text was updated successfully, but these errors were encountered: