Skip to content
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

Update documentation generation example in developer-notes.md #337

Closed
wants to merge 97 commits into from

Conversation

l0rinc
Copy link

@l0rinc l0rinc commented Aug 18, 2024

Split out of bitcoin#30454

In the other readme we've provided a default build directory instead.

MarcoFalke and others added 24 commits July 12, 2024 11:18
Also, remove the value_type alias, which is not needed when element_type
is present.
Replace std::equal with std::ranges::equal, because it allows for
shorter code, because no pointers or iterators have to be passed
explicitly.
It is expensive to construct, and only one test uses it.

Fix both issues by disallowing the construction and moving it to the
single test that uses it.
In 6bfa260 the testnet4 timewarp
attack fix block time variation was increased from the Great
Consensus Cleanup value of 600s to 7200s on the thesis that this
allows miners to always create blocks with the current time. Sadly,
doing so does allow for some nonzero inflation, even if not a huge
amount.

While it could be that some hardware ignores the timestamp provided
to it over Stratum and forces the block header timestamp to the
current time, I'm not aware of any such hardware, and it would also
likely suffer from random invalid blocks due to relying on NTP
anyway, making its existence highly unlikely.

This leaves the only concern being pools, but most of those rely on
work generated by Bitcoin Core (in one way or another, though when
spy mining possibly not), and it seems likely that they will also
not suffer any lost work. While its possible that a pool does
generate invalid work due to spy mining or otherwise custom logic,
it seems unlikely that a substantial portion of hashrate would do
so, making the difference somewhat academic (any pool that screws
this up will only do so once and the network would come out just
fine).

Further, while we may end up deciding these assumptions were
invalid and we should instead use 7200s, it seems prudent to try
with the value we "want" on testnet4, giving us the ability to
learn if the compatibility concerns are an issue before we go to
mainnet.
Update the user agent regex to match all 3 digits of the version number,
not just the first 2 digits.

Also updates it to include 24.2, 25.2, 26.1, 27.0, 27.1, 27.99, 28.0 and
28.99.
The crawlers are not guaranteed to output nodes in a random order, so
shuffle the ips list after parsing to break any biasing that may be
caused by the output order.
The re-init is expensive, so skip it if there is no need.

Also, add an even faster fuzz target utxo_snapshot_invalid, which does
not need any re-init at all.
The seeders now produce onion and i2p seeds, so there is no need to keep these
in the manual list.

Although should also be produced, there are not enough
good ones detected by the seeder, so we keep the manual seeds for them.
Update the fixed seeds for both mainnet and testnet
@l0rinc l0rinc marked this pull request as ready for review August 18, 2024 19:34
@hebasto hebasto added the documentation Docs and manuals label Aug 19, 2024
achow101 and others added 4 commits August 19, 2024 15:15
…00s from 7200s

16e95bd Move maximum timewarp attack threshold back to 600s from 7200s (Matt Corallo)

Pull request description:

  In 6bfa260 the testnet4 timewarp attack fix block time variation was increased from the Great Consensus Cleanup value of 600s to 7200s on the thesis that this allows miners to always create blocks with the current time. Sadly, doing so does allow for some nonzero inflation, even if not a huge amount.

  While it could be that some hardware ignores the timestamp provided to it over Stratum and forces the block header timestamp to the current time, I'm not aware of any such hardware, and it would also likely suffer from random invalid blocks due to relying on NTP anyway, making its existence highly unlikely.

  This leaves the only concern being pools, but most of those rely on work generated by Bitcoin Core (in one way or another, though when spy mining possibly not), and it seems likely that they will also not suffer any lost work. While its possible that a pool does generate invalid work due to spy mining or otherwise custom logic, it seems unlikely that a substantial portion of hashrate would do so, making the difference somewhat academic (any pool that screws this up will only do so once and the network would come out just fine).

  Further, while we may end up deciding these assumptions were invalid and we should instead use 7200s, it seems prudent to try with the value we "want" on testnet4, giving us the ability to learn if the compatibility concerns are an issue before we go to mainnet.

ACKs for top commit:
  fjahr:
    tACK 16e95bd
  achow101:
    ACK 16e95bd
  murchandamus:
    crACK 16e95bd

Tree-SHA512: ae46d03b728b6e23cb6ace64c9813bc01c01e38dd7f159cf0fab53b331ef84b3b811edab225453ccdfedb53b242f55b0efd69829782657490fe393d24dacbeb2
This speeds up the fuzz target, which allows "valid" inputs. It does not
affect the "INVALID" fuzz target.
This currently has no effect due to fPowNoRetargeting,
except for the getnetworkhashps when called with -1.

It will when the next commit enforces the timewarp attack mitigation on regtest.
hodlinator and others added 20 commits August 27, 2024 11:14
Ran scripted-diff from 2d9d752.

Follow-up to bitcoin#29775 which overlapped with work on bitcoin#30560 (the latter includes the scripted-diff commit).
…in p2p_ibd_stalling

fa5b58e test: Avoid intermittent block download timeout in p2p_ibd_stalling (MarcoFalke)

Pull request description:

  Fixes bitcoin#30704

  The goal of the test is to check the stalling timeout, not the block download timeout.

  On extremely slow hardware (for example qemu virtual hardware), downloading the 1023 blocks may take longer than the block download timeout.

  Fix it by pinning the time using mocktime, and only advance it when testing the stalling timeout.

ACKs for top commit:
  tdb3:
    CR ACK fa5b58e
  brunoerg:
    utACK fa5b58e

Tree-SHA512: 9a9221f264bea52be5e9fe81fd319f5a6970cd315cc5e9f5e2e049c5d84619b19b9f6f075cda8d34565c2d6c17a88fb57e195c66c271e40f73119a77caecb6d7
c88a7dc chainparams: Remove seed.bitcoinstats.com (Ava Chow)

Pull request description:

  This seeder no longer appears to be serving sufficient addresses.

  Fixes bitcoin#29911

ACKs for top commit:
  1440000bytes:
    ACK bitcoin@c88a7dc
  virtu:
    ACK bitcoin@c88a7dc
  mzumsande:
    ACK c88a7dc
  BrandonOdiwuor:
    ACK c88a7dc

Tree-SHA512: 23db3a217bbc3cd96785f17bd2b1db886392cc864dfc00498fa30e69df414ad02cb35f34cd6b7e8adab7c024a7efa8fd4a39b8b8ef274d95974cb16eb1c39a5b
…tes from Chain Interface

1b41d45 wallet: bugfix: ensure atomicity in settings updates (ismaelsadeeq)

Pull request description:

  This PR fixes bitcoin#30620.

  As outlined in the issue, creating two wallets with `load_on_startup=true` simultaneously results in only one wallet being added to the startup file.

  The current issue arises because the wallet settings update process involves:
  1. Obtaining the settings value while acquiring the settings lock.
  2. Modifying the settings value.
  3. Overwriting the settings value while acquiring the settings lock again.

  This sequence is not thread-safe. Different threads could modify the same base value simultaneously, overwriting data from other workers without realizing it.

  The PR attempts to  fix this by modifying the chain interface's `updateRwSetting` method to accept a function that will be called with the settings reference. This function will either update or delete the setting and return an enum indicating whether the settings need to be overwritten in this or not.

  Additionally, this PR introduces two new methods to the chain interface:
  - `overwriteRwSetting`: This method replaces the setting with a new value.
  Used in `VerifyWallets`
  - `deleteRwSettings`: This method completely erases a specified setting.
  This method is currently used only in `overwriteRwSetting`.

  These changes ensure that updates are race-free across all clients.

ACKs for top commit:
  achow101:
    ACK 1b41d45
  furszy:
    self-code-ACK bitcoin@1b41d45

Tree-SHA512: 50cda612b782aeb5e03e2cf63cc44779a013de1c535b883b57af4de22f24b0de80b4edecbcda235413baec0a12bdf0e5750fb6731c9e67d32e742d8c63f08c13
…e requirements for Onion and I2P nodes

b061b35 seeds: Regenerate mainnet seeds (virtu)
02dc45c seeds: Pull nodes from Luke's seeder (virtu)
7a2068a seeds: Pull nodes from virtu's crawler (virtu)

Pull request description:

  This builds on bitcoin#30008 and adds data [exported](https://github.com/virtu/seed-exporter) by [my crawler](https://github.com/virtu/p2p-crawler) an additional source for seed nodes. Data covers all supported network types.

  [edit: Added Luke's seeder as input as well.]

  ### Motivation
  - Further decentralizes the seed node selection process (in the long term potentially enabling an _n_-source threshold for nodes to prevent a single source from entering malicious nodes)
  - No longer need to manually curate seed node list for any network type: See last paragraph of OP in bitcoin#30008. My crawler has been [discovering the handful of available cjdns nodes](https://21.ninja/reachable-nodes/nodes-by-net-type/) for around two months, all but one of which meet the reliability criteria.
  - Alignment of uptime requirements for Onion and I2P nodes with those of clearnet nodes to 50%: If I'm reading the code correctly, seeders appear to optimize for up-to-dateness by using [lower connection timeouts](https://github.com/achow101/dnsseedrs/blob/3c1a63c6723819871d76fe0fbd2155fe5a5bb171/src/crawl.rs#L349) than [Bitcoin Core](https://github.com/bitcoin/bitcoin/blob/bc87ad98543299e1990ee1994d0653df3ac70093/src/netbase.cpp#L40C27-L40C48) to maximize throughput. Since my crawler does not have the same timeliness requirements, it opts for accuracy by using generous timeouts. As a result, its data contains additional eligible Onion (and other darknet nodes), as is shown in the histogram below. Around 4500 Onion nodes are discovered so far (blue); my data adds ~6400 more (orange); ~ 1500 nodes take longer than the default 20-second Bitcoin Core timeout and won't qualify as "good".

  ![Connection time histogram for Onion nodes](https://github.com/user-attachments/assets/c3513604-aa48-4c75-b51d-13421eaed9eb)

  Here's the current results with 512 nodes for all networks except cjdns:
  <details>
  <summary>Using the extra data</summary>

  ```
  IPv4   IPv6  Onion  I2P    CJDNS Pass
  10335   2531  11545   1589     10 Initial
  10335   2531  11545   1589     10 Skip entries with invalid address
  5639   1431  11163   1589      8 After removing duplicates
  5606   1417  11163   1589      8 Enforce minimal number of blocks
  5606   1417  11163   1589      8 Require service bit 1
  4873   1228  11163   1589      8 Require minimum uptime
  4846   1225  11161   1588      8 Require a known and recent user agent
  4846   1225  11161   1588      8 Filter out hosts with multiple bitcoin ports
  512    512    512    512      8 Look up ASNs and limit results per ASN and per net
  ```
  </details>
  <details>
  <summary>Before</summary>

  ```
  IPv4   IPv6  Onion  I2P    CJDNS Pass
  5772   1323    443      0      2 Initial
  5772   1323    443      0      2 Skip entries with invalid address
  4758   1110    443      0      2 After removing duplicates
  4723   1094    443      0      2 Enforce minimal number of blocks
  4723   1094    443      0      2 Require service bit 1
  3732    867    443      0      2 Require minimum uptime
  3718    864    443      0      2 Require a known and recent user agent
  3718    864    443      0      2 Filter out hosts with multiple bitcoin ports
   512    409    443      0      2 Look up ASNs and limit results per ASN and per net
  ```
  </details>

  ### To dos
  - [x] Remove manual nodes and update README
  - [x] Mark nodes with connection times exceeding Bitcoin Core's default as bad in [exporter](https://github.com/virtu/seed-exporter): [done](virtu/seed-exporter#12)
  - [x] Regenerate mainnet seeds
  - [x] Rebase, then remove WIP label once bitcoin#30008 gets merged

ACKs for top commit:
  achow101:
    ACK b061b35
  fjahr:
    utACK b061b35

Tree-SHA512: 63e86220787251c7e8d2d5957bad69352e19ae17d7b9b2d27d8acddfec5bdafe588edb68d77d19c57f25f149de723e2eeadded0c8cf13eaca22dc33bd8cf92a0
1bf9b70 docs: Add 379 and 387 to bips.md (Ava Chow)
35ef34e docs: Remove release 28.0 release notes fragments (Ava Chow)
f5cf43b build: Bump to 28.99 (Ava Chow)

Pull request description:

  * Bump to 28.99 in preparation for the 28.x branching
  * Remove current release note fragments. They've been moved to [draft release notes]((https://github.com/bitcoin-core/bitcoin-devwiki/wiki/28.0-Release-Notes-Draft).) in the wiki.
  * Updated bips.md with missing BIPs that were implemented a while ago.

ACKs for top commit:
  maflcko:
    lgtm ACK 1bf9b70
  tdb3:
    re ACK 1bf9b70

Tree-SHA512: 9d5b05330268bb233369d78f06011dbdcdcb87770c499ae743ac4833735ba657b6611ff1e332c9d4added854b694c5a3a961d911247303f7ddaaaa72149d5574
fab0e83 bench: [refactor] iwyu (MarcoFalke)

Pull request description:

  Missing includes are problematic, because:

  * Upcoming releases of a C++ standard library implementation often minimize their internal header dependencies. For example, `_LIBCPP_REMOVE_TRANSITIVE_INCLUDES` (https://libcxx.llvm.org/DesignDocs/HeaderRemovalPolicy.html). This can lead to compile failures, which are easy to fix for developers, but may not be for users. For example, commit 138f867 had to add missing includes to accommodate GCC 15 (and the commit had to be backported).
  * A Bitcoin Core developer removing a feature from a module and wanting to drop the now unused includes may not be able to do so without touching other unrelated files, because those files rely on the transitive includes.

  Moreover, missing or extraneous includes are problematic, because they may be confusing the code reader as to what the real dependencies are.

  Finally, extraneous includes may slow down the build.

  Fix all issues in `bench`, by applying the rule include-what-you-use (iwyu).

  Follow-up pull requests will handle the other places.

ACKs for top commit:
  hodlinator:
    ACK fab0e83
  achow101:
    ACK fab0e83
  TheCharlatan:
    ACK fab0e83
  hebasto:
    ACK fab0e83.
  brunoerg:
    crACK fab0e83
  stickies-v:
    ACK fab0e83

Tree-SHA512: f079c05d3ddebafabbd5a6c76d43d17337d1a962b97ba0ee27612f91c58491e7ce4e4229be54bd6e75a15512798c6f59925d0a076a37c050f8b9ef455ae5c9a2
…d::input_iterator

fa7b9b9 refactor: Require std::input_iterator for all InputIterator in prevector (MarcoFalke)
d444441 refactor: Allow CScript construction from any std::input_iterator (MarcoFalke)

Pull request description:

  Currently only (pre)vector iterators and raw pointers are accepted. However, this makes it harder to construct from input iterators provided by other classes, such as `std::span`.

  Fix that.

ACKs for top commit:
  delta1:
    reACK fa7b9b9
  achow101:
    ACK fa7b9b9
  hodlinator:
    ACK fa7b9b9
  ryanofsky:
    Code review ACK fa7b9b9

Tree-SHA512: 2760861f8bce42fb27dc0825e61621cb157f1ac3619a0834df38eb8319b6dcf9de43d90397a4c160f43340880c1553df638848e9057a27c792214331243ef4a5
18d65d2 test: use uint256::FromUserHex for RANDOM_CTX_SEED (stickies-v)
6819e5a node: use uint256::FromUserHex for -assumevalid parsing (stickies-v)
2e58fdb util: remove unused IsHexNumber (stickies-v)
8a44d7d node: use uint256::FromUserHex for -minimumchainwork parsing (stickies-v)
70e2c87 refactor: add uint256::FromUserHex helper (stickies-v)
85b7cbf test: unittest chainstatemanager_args (stickies-v)

Pull request description:

  Since fad2991, `uint256S` has been [deprecated](bitcoin@fad2991#diff-800776e2dda39116e889839f69409571a5d397de048a141da7e4003bc099e3e2R138) because it is less robust than the `base_blob::FromHex()` introduced in [the same PR](bitcoin#30482). Specifically, it tries to recover from length-mismatches, recover from untrimmed whitespace, 0x-prefix and garbage at the end, instead of simply requiring exactly 64 hex-only characters. _(see also bitcoin#30532)_

  This PR carves out the few `uint256S` callsites that may potentially prove a bit more controversial to change because they deal with user input and backwards incompatible behaviour change.

  The main behaviour change introduced in this PR is:
  - `-minimumchainwork` will raise an error when input is longer than 64 hex digits
  - `-assumevalid` will raise an error when input contains invalid hex characters, or when it is longer than 64 hex digits
  - test: the optional RANDOM_CTX_SEED env var will now cause tests to abort when it contains invalid hex characters, or when it is longer than 64 hex digits

  After this PR, the remaining work to remove `uint256S` completely is almost entirely mechanical and/or test related. I will open that PR once bitcoin#30560 is merged because it builds on that.

ACKs for top commit:
  hodlinator:
    re-ACK 18d65d2
  l0rinc:
    ACK 18d65d2
  achow101:
    ACK 18d65d2
  ryanofsky:
    Code review ACK 18d65d2. Very nice change that cleans up the API, adds checking for invalid values, makes parsing of values more consistent, and adds test coverage.

Tree-SHA512: ec118ea3d56e1dfbc4c79acdbfc797f65c4d2107b0ca9577c848b4ab9b7cb8d05db9f3c7fe8441a09291aca41bf671572431f4eddc59be8fb53abbea76bbbf86
…uint256{"str"}

49f9b64 refactor: Testnet4 - Replace uint256S("str") -> uint256{"str"} (Hodlinator)

Pull request description:

  Ran scripted-diff from 2d9d752:
  ```
  sed -i --regexp-extended -e 's/\buint256S\("(0x)?([^"]{64})"\)/uint256{"\2"}/g' $(git grep -l uint256S)
  ```

  Follow-up to Testnet4 introduction bitcoin#29775 which overlapped with work on `uint256` `consteval` ctor bitcoin#30560 (the latter includes the scripted-diff commit).

  Going forward `uint256{}` should be used for constants instead of `uint256S()`.

ACKs for top commit:
  maflcko:
    review-ACK 49f9b64 🐮
  fjahr:
    ACK 49f9b64

Tree-SHA512: 94fe5d9f1fb85e9ce5c3c4c5e4c31667e8cbb55ee691a4b5b3ae4172ccac38230281071023663965917f188b4c19bdf67afd4e3cdf69d89e97c65faea88af833
8dec4e1 fuzz: fix timeout in `crypto_fschacha20poly1305` (brunoerg)

Pull request description:

  Fixes bitcoin#30505

  This PR fixes a timeout in `crypto_fschacha20poly1305` by reducing the number of iterations. I left it running for a while and noticed it speeds up the target and do not impact coverage.

ACKs for top commit:
  maflcko:
    lgtm ACK 8dec4e1
  stratospher:
    ACK 8dec4e1. saw similar coverage stats (these are from different machines, saw more similar from same machine).

Tree-SHA512: 66cd689f10f09cf880c1f2c77aa481336a95a7e10b655d156b2dc9cd38165670000019a6fb3775485ccb5cce248939a52a31ebd755a6befed6274cc841d21d97
…s::equal

fad0cf6 refactor: Use std::ranges::equal in GetNetworkForMagic (MarcoFalke)
fadf0a7 refactor: Remove Span operator==, Use std::ranges::equal (MarcoFalke)

Pull request description:

  `std::span` removed the comparison operators, so it makes sense to remove them for the `Span` "backport" as well. Using `std::ranges::equal` also has the benefit that some `Span` temporary constructions can now be dropped.

  This is required to move from `Span` toward `std::span`.

ACKs for top commit:
  hodlinator:
    Untested Code Review re-ACK fad0cf6
  stickies-v:
    ACK fad0cf6
  TheCharlatan:
    ACK fad0cf6

Tree-SHA512: 5b9d1826ceac2aabae2295bc89893dd23ac3a1cc0d41988331cdbdc21be531aa91795d5273819f349f79648c6c4f30ed31af6e7a3816153e92080061b92ffe00
4105129 cmake: Ignore build subdirectories within source directory (Hennadii Stepanov)
6ce50fd doc: Update for CMake-based build system (Hennadii Stepanov)
9730288 ci: Migrate CI scripts to CMake (Hennadii Stepanov)
c360837 cmake, lint: Adjust `lint_includes_build_config` (Hennadii Stepanov)
3885441 cmake: Add presets for native Windows builds (Hennadii Stepanov)
7681746 cmake: Add vcpkg manifest file (Hennadii Stepanov)
8b6f1c4 cmake: Add `Coverage` and `CoverageFuzz` scripts (Hennadii Stepanov)
65bdbc1 cmake: Add `docs` build target (Hennadii Stepanov)
fb75ebb cmake: Add compiler diagnostic flags (Hennadii Stepanov)
e821f0a cmake: Migrate Guix build scripts to CMake (Hennadii Stepanov)
747adb6 cmake: Add `Maintenance` module (Hennadii Stepanov)
1f60b30 cmake: Add `APPEND_{CPP,C,CXX,LD}FLAGS` cache variables (Hennadii Stepanov)
2b43c45 cmake: Add `AddWindowsResources` module (Hennadii Stepanov)
973a3b0 cmake: Implement `install` build target (Hennadii Stepanov)
84ac35c cmake: Add cross-compiling support (Hennadii Stepanov)
0d01c22 build: Generate `toolchain.cmake` in depends (Hennadii Stepanov)
91a7992 depends: Add host-specific `cmake_system_version` variables (Hennadii Stepanov)
9b31209 depends: Rename `cmake_system` -> `cmake_system_name` (Hennadii Stepanov)
4a5208a Revert "build, qt: Do not install *.prl files" (Hennadii Stepanov)
6522af6 depends: Amend handling flags environment variables (Hennadii Stepanov)
90cec4d cmake: Add `MULTIPROCESS` option (Hennadii Stepanov)
bb1a450 cmake: Build `bitcoin-chainstate` executable (Hennadii Stepanov)
aed38ea cmake: Build `bitcoinkernel` library (Hennadii Stepanov)
975d673 cmake: Build `test_bitcoin-qt` executable (Hennadii Stepanov)
10fcc66 cmake: Add `WITH_DBUS` option (Hennadii Stepanov)
5bb5a4b cmake: Add `libqrencode` optional package support (Hennadii Stepanov)
57a6e2e cmake: Build `bitcoin-qt` executable (Hennadii Stepanov)
30f6429 cmake: Add `WERROR` option (Hennadii Stepanov)
c98d4a4 cmake: Add `REDUCE_EXPORTS` option (Hennadii Stepanov)
a01cb6e cmake: Add `HARDENING` option (Hennadii Stepanov)
a8a2e36 cmake: Add Python-based tests (Hennadii Stepanov)
3d85379 cmake: Add fuzzing options (Hennadii Stepanov)
908530e cmake: Add `SANITIZERS` option (Hennadii Stepanov)
8bb0e85 cmake: Build `bench_bitcoin` executable (Hennadii Stepanov)
8017351 cmake: Add external signer support (Hennadii Stepanov)
353e0c9 cmake: Add `systemtap-sdt` optional package support (Hennadii Stepanov)
d2fda82 cmake: Add `libzmq` optional package support (Hennadii Stepanov)
ae7b39a cmake: Add `libminiupnpc` optional package support (Hennadii Stepanov)
6480e1d cmake: Add `libnatpmp` optional package support (Hennadii Stepanov)
e73e930 cmake: Build `bitcoin-util` executable (Hennadii Stepanov)
027c6d7 cmake: Build `bitcoin-tx` executable (Hennadii Stepanov)
d10c5c3 cmake: Add wallet functionality (Hennadii Stepanov)
ab2e99b cmake: Create test suite for `ctest` (Hennadii Stepanov)
959370b cmake: Build `test_bitcoin` executable (Hennadii Stepanov)
b27bf97 cmake: Build `bitcoin-cli` executable (Hennadii Stepanov)
a9813df cmake: Build `bitcoind` executable (Hennadii Stepanov)
97829ce cmake: Add `FindLibevent` module (Hennadii Stepanov)
3118e40 cmake: Build `bitcoin_consensus` library (Hennadii Stepanov)
809a2f1 cmake: Build `bitcoin_util` static library (Hennadii Stepanov)
0a9a521 cmake: Build `bitcoin_crypto` library (Hennadii Stepanov)
958971f cmake: Build `univalue` static library (Hennadii Stepanov)
752747f cmake: Generate `obj/build.h` header (Hennadii Stepanov)
1f0a78e cmake: Build `minisketch` static library (Hennadii Stepanov)
12bfbc8 cmake: Build `leveldb` static library (Hennadii Stepanov)
51985c5 cmake: Build `crc32c` static library (Hennadii Stepanov)
db7a198 cmake: Build `secp256k1` subtree (Hennadii Stepanov)
dbb7ed1 cmake: Add `ccache` support (Hennadii Stepanov)
cedfdf6 cmake: Redefine/adjust per-configuration flags (Hennadii Stepanov)
b6b5e73 cmake: Add global compiler and linker flags (Hennadii Stepanov)
f983279 cmake: Add `TryAppendLinkerFlag` module (Hennadii Stepanov)
4a0af29 cmake: Add `TryAppendCXXFlags` module (Hennadii Stepanov)
35cffc4 cmake: Add POSIX threads support (Hennadii Stepanov)
fd72d00 cmake: Add position independent code support (Hennadii Stepanov)
07069e2 cmake: Add introspection module (Hennadii Stepanov)
27d687f cmake: Add `config/bitcoin-config.h` support (Hennadii Stepanov)
fe5cdac cmake: Print compiler and linker flags in summary (Hennadii Stepanov)
7068388 cmake: Introduce interface libraries to encapsulate common flags (Hennadii Stepanov)
a2317e2 cmake: Add root `CMakeLists.txt` file (Hennadii Stepanov)

Pull request description:

  This PR introduces a new CMake-based build system, which is a drop-in replacement for the current Autotools-based build system.

  ML announcement: https://groups.google.com/g/bitcoindev/c/hgKkfQWzrTo

  As discussed during the recent CoreDev meetup in April, the switch from Autotools to CMake is intended to happen as soon as possible after branching 28.x off, which means that 29.0 will be built using CMake.

  This PR branch is essentially the [staging branch](https://github.com/hebasto/bitcoin/tree/cmake-staging), with every change reviewed and tested by a group of contributors, including (in alphabetical order):
  - [**achow101**](https://github.com/achow101)
  - [**fanquake**](https://github.com/fanquake)
  - [**maflcko**](https://github.com/maflcko)
  - [**m3dwards**](https://github.com/m3dwards)
  - [**pablomartin4btc**](https://github.com/pablomartin4btc)
  - [**real-or-random**](https://github.com/real-or-random)
  - [**ryanofsky**](https://github.com/ryanofsky)
  - [**sipsorcery**](https://github.com/sipsorcery)
  - [**TheCharlatan**](https://github.com/TheCharlatan)
  - [**theStack**](https://github.com/theStack)
  - [**theuni**](https://github.com/theuni)
  - [**vasild**](https://github.com/vasild)

  Reviewing in a separate staging repo was suggested in bitcoin#27060 (comment).

  The accompanying changes to the OSS-Fuzz project are available in hebasto/oss-fuzz#8.

  Please refer to the [build options parity table](https://gist.github.com/hebasto/2ef97d3a726bfce08ded9df07f7dab5e). The "auto" value is no longer available; non-default values must be specified explicitly. Additionally, the new default values have been chosen to suit the everyday build experience for the majority of developers.

  System requirements for using the CMake-based build system:
  - CMake >= 3.22 (if not available in your system's repository, it can be downloaded from https://cmake.org/download/)
  - a build tool of your choice:
  - any Make (GNU Make is no longer a requirement); GNU Make is still required to build depends
  - Ninja (https://ninja-build.org/)
  - MSBuild
  - Xcode

  A note for Windows users: The default installation of the latest version of MSVC 17.10.4 includes both CMake 3.28.3 and the vcpkg package manager).

  ---

  We, the build system developers, kindly ask reviewers to refrain from making suggestions that are not directly related to the migration process or can be implemented separately. Bugs in the scripts and errors in the updated documentation should be the focus of this PR. Please be advised that comments not aligned with this PR's goal may be ignored.

  Thank you all for your understanding.

ACKs for top commit:
  maflcko:
    review ACK 4105129 🐥
  sipsorcery:
    ACK 4105129.
  vasild:
    ACK 4105129
  TheCharlatan:
    ACK 4105129
  pablomartin4btc:
    tACK 4105129
  i-am-yuvi:
    tACK [`4105129`](bitcoin@4105129)
  theuni:
    ACK 4105129.
  fanquake:
    ACK 4105129

Tree-SHA512: 6c1445054436c6c00ad63bfa0f19d64091a2b25c9bd694f85bf2218ac358ffb774d6c000685b3ca1e9b50401babed989fa2a0694b774c211d226bfd1944c9b39
CMake was merged after branching-off for 28.x.
fa0e1e4 fuzz: Add missing fuzz targets to cmake build (MarcoFalke)

Pull request description:

  Fixes bitcoin#30454 (comment)

  Can be tested via:

  ```
  PRINT_ALL_FUZZ_TARGETS_AND_ABORT=1 ./bld-autot/src/test/fuzz/fuzz > /tmp/f_autot
  PRINT_ALL_FUZZ_TARGETS_AND_ABORT=1 ./bld-cmake/src/test/fuzz/fuzz > /tmp/f_cmake
  diff --unified /tmp/{f_autot,f_cmake}

ACKs for top commit:
  hebasto:
    ACK fa0e1e4

Tree-SHA512: 460ae650eae3c2b8936f48bff8c2b85cf3c2ccaf418109d1be9c5a32f9322bb500c7809cb3e81d5ffd24bf5e982ecedbbd7e04059ad60701f2ede9e3ba4a5804
680f05e build: fix version number post CMake (fanquake)

Pull request description:

  CMake was merged after branching-off for `28.x`.

ACKs for top commit:
  hebasto:
    ACK 680f05e
  TheCharlatan:
    ACK 680f05e
  vasild:
    ACK 680f05e

Tree-SHA512: 18e10a49830b529f54f7c9ed81ff0489f9aac9779f34935ebe0051c742f3b7862ca5d3409a6d6347c2d9c6439dcdd1394333278308012fed473f5b00d80afdd5
@hebasto
Copy link
Owner

hebasto commented Aug 28, 2024

Since bitcoin#30454 has been merged, further development in this repository no longer makes sense. Please consider moving this PR to the main repository.

hebasto and others added 6 commits August 28, 2024 12:00
371910a depends: Fix CMake-generated `libzmq.pc` file (Hennadii Stepanov)

Pull request description:

  This is a backport of: zeromq/libzmq#4706.

  Similar to bitcoin#30488.

  Addresses bitcoin#29723 (comment):
  > Looking at the mingw .pc generated by this PR:
  >
  > ```
  > Libs: -L${libdir} -lzmq
  > Libs.private:
  > Requires.private:
  > ```
  >
  > It looks like we'll need to take [zeromq/libzmq#4706](zeromq/libzmq#4706) as well for CMake. That can be done as a follow-up though, as it's not yet merged upstream.

ACKs for top commit:
  fanquake:
    ACK 371910a

Tree-SHA512: 6f9c2e32f83c0e629e32fd3e4c86712af00ffeaf0906bf85e5c2df889302707b9df102e8031249d1bae036eb4fc019c2a5124655682fbc5652d9337cb21c5f2c
This has been superseded by CMake.
04fb085 build: remove old MSVC build system (fanquake)

Pull request description:

  This has been superseded by CMake, and should not be blocked on anything for removal.

ACKs for top commit:
  laanwj:
    ACK 04fb085
  hebasto:
    ACK 04fb085.
  TheCharlatan:
    ACK 04fb085
  vasild:
    ACK 04fb085, except:

Tree-SHA512: 219005bd0de1a9e37dabe45c979601df3083368f4c5ea224f70cf4e6f52e49d8f25713015ce005be3b34b56377eaafa339be7c50c63ce7f3ce7841ae55f3221f
To correspond to the documentation style of e.g.  src/test/README.md

Co-authored-by: pablomartin4btc <pablomartin4btc@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Docs and manuals
Projects
None yet
Development

Successfully merging this pull request may close these issues.