Library source code organization

MarcoFalke commented at 7:05 pm on April 3, 2019: member

(copied from #15638 (comment) by @ryanofsky) Here is how I am thinking about the organization:

libbitcoin_server.a, libbitcoin_wallet.a, and libbitcoinqt.a should all be terminal dependencies. They should be able to depend on other symbols in other libraries, but no other libraries should depend on symbols in them (and they shouldn’t depend on each other).
libbitcoin_consensus.a should be a standalone library that doesn’t depend on symbols in other libraries mentioned here
libbitcoin_common.a and libbitcoin_util.a seem very interchangeable right now and mutually depend on each other. I think we should either merge them into one library, or create a new top-level src/common/ directory complementing src/util/, and start to distinguish general purpose utility code (like argument parsing) from bitcoin-specific utility code (like formatting bip32 paths and using ChainParams). Both these libraries can be depended on by libbitcoin_server.a, libbitcoin_wallet.a, and libbitcoinqt.a, and they can depend on libbitcoin_consensus.a. If we want to split util and common up, as opposed to merging them together, then util shouldn’t depend on libconsensus, but common should.

Over time, I think it’d be nice if source code organization reflected library organization . I think it’d be nice if all libbitcoin_util source files lived in src/util, all libbitcoin_consensus.a source files lived in src/consensus, and all libbitcoin_server.a code lived in src/node (and maybe the library was called libbitcoin_node.a).

MarcoFalke added the label Brainstorming on Apr 3, 2019

MarcoFalke added the label Build system on Apr 3, 2019

MarcoFalke commented at 7:06 pm on April 3, 2019: member

See also:

Source code organization for standalone (util) functions and types #14721

laanwj commented at 1:20 pm on April 10, 2019: member

libbitcoin_common.a and libbitcoin_util.a seem very interchangeable right now and mutually depend on each other

interesting—util is linked by:

0bitcoind
1bitcoin-cli
2bitcoin-tx
3bitcoin-wallet
4bench/bench_bitcoin
5qt/bitcoin-qt
6qt/test/test_bitcoin-qt
7test/test_bitcoin

whereas common is linked by:

0bitcoind
1bitcoin-tx
2bitcoin-wallet
3bench/bench_bitcoin
4qt/bitcoin-qt
5qt/test/test_bitcoin-qt
6test/test_bitcoin

The only difference being bitcoin-cli. Yes, with this I’d say it makes sense to merge them, unless the current split avoids pulling in some dependencies for bitcoin-cli (@luke-jr might be able to comment w.r.t. gentoo). This can’t be true if there are bidirectional dependencies between them.

sipa commented at 2:36 pm on April 10, 2019: member

Concept ACK on the organization plan above.

I feel that there is place for a distinction between common and util, through the question “bitcoin specific logic”. For example, transaction signing seems to belong in a very different place than command-line handling logic, and bitcoin-cli shouldn’t need to include the former.

However it seems that in practice this distinction isn’t really followed, so it may be better to just merge common and util to remove the mutual dependency, and the later carve out the real “util” parts.

hebasto commented at 3:11 pm on September 25, 2021: member

it’d be nice if source code organization reflected library organization

Concept ACK.

practicalswift commented at 8:25 am on September 30, 2021: contributor

Concept ACK

MarcoFalke referenced this in commit 816e15ee81 on Oct 5, 2021

fanquake referenced this in commit c53e95f22c on Oct 21, 2021

MarcoFalke referenced this in commit ca6163550c on Nov 6, 2021

MarcoFalke referenced this in commit c561f2f06e on Jan 11, 2022

MarcoFalke commented at 7:49 pm on February 10, 2022: member

Library source code organization #15732