build: Introduce CMake-based build system #30454

In commit ff368465a66298487a88d8da575f5251d094d687

Could you remind me what’s going on here, please? I assume these aren’t needed because we’re meant to be adding compile definitions to specific libs. But from what I can tell, we’re not actually adding them to sha256.cpp? So… is this currently using an un-optimized sha2?

Generally I’d feel more comfortable turning these into opt-outs, I think, to avoid accidentally building without optims.

For the sake of review/sanity, I think for this commit it’s worth documenting (in the commit message) exactly which defines are affected and where in CMake they’ve been added.

But from what I can tell, we’re not actually adding them to sha256.cpp? So… is this currently using an un-optimized sha2?

Please note the PUBLIC keyword, which propagates the definition as a usage requirement: https://github.com/bitcoin/bitcoin/blob/2b7c0f4fdb81ec1cf0579fa71b37f56672934ab5/src/crypto/CMakeLists.txt#L125

and

https://github.com/bitcoin/bitcoin/blob/2b7c0f4fdb81ec1cf0579fa71b37f56672934ab5/src/crypto/CMakeLists.txt#L128

where that usage requirement is actually applied.

The same approach works for other definitions used in src/crypto/sha256.cpp.

For the sake of review/sanity, I think for this commit it’s worth documenting (in the commit message) exactly which defines are affected and where in CMake they’ve been added.

Sure thing! I’ll update the commit message during the next branch update.

One can see that they are indeed disabled now in https://corecheck.dev/bitcoin/bitcoin/pulls/30454 (coverage report + benchmarks).

Shouldn’t autotools be nuked in this pull request, assuming that cmake and autotools are apparently incompatible, as designed now?

@theuni @maflcko

Can you confirm please that the recent push resolved this issue?

Hmm https://corecheck.dev/bitcoin/bitcoin/pulls/30454 is down again

It is up now :)

Hmm https://corecheck.dev/bitcoin/bitcoin/pulls/30454 is down again

It is up now :)

Nice. The output there looks better now. But I haven’t yet tried locally.

Done in #30523.

See https://github.com/hebasto/bitcoin/pull/284.

None of these package are required for the native build with CMake.

Correct. I was mostly trying to say that packages required for a native build are not listed here again as a dependency for a native (non-cross) depends build. Otherwise, autoconf automake should be listed here as well, because they are still required for some depends packages? In any case you are removing autoconf automake and gmake from the instructions in doc/build-openbsd.md, so overall it seems a bit inconsistent?

Otherwise, autoconf automake should be listed here as well, because they are still required for some depends packages? In any case you are removing autoconf automake and gmake from the instructions in doc/build-openbsd.md, so overall it seems a bit inconsistent?

I agree that this issue has to be resolved in depends/README.md.

Otherwise, autoconf automake should be listed here as well, because they are still required for some depends packages?

Apparently, they are not. Thanks to the recent migration of dependency packages to CMake.

cc @theStack

Apparently, they are not.

SQLite still uses Autotools?

Ok, I see. I just completed on current master a depends on Linux build without any of autoconf automake autotools-dev libtool. Possibly they could be removed from the Common section above, but that seems unrelated to this pull request.

Just to clarify, removing gmake from the instructions in doc/build-openbsd.md is also intentional in this pull request?

Just to clarify, removing gmake from the instructions in doc/build-openbsd.md is also intentional in this pull request?

Yes, it is. CMake can work with any flavour of Make, so GNU Make is not longer a requirement.

Apparently, they are not.

SQLite still uses Autotools?

The sqlite-autoconf-3380500.tar.gz archive contains pre-built configure script and Makefile.in file. Therefore, Autotools is not required on our side.

Autotools might not be used currently for sqlite (libtool still is), but we can’t rule out entirely that it wont be used going forward. For example, if we need to regenerate the configure script for some reason. This has happened in the past, for example, something like 6897c4bdf51a4aa74320ebfffa9467db14670109. This might be very unlikely here, but not impossible.

Note that this would also breakdown, if we were to shift to building from source (requiring us to generate the build scripts oursevles), rather than using the tarballs with everything pre-generated (and unverifiable/opauge). (In this case it’d also be all of the Linux GUI packages that’d require it).

Autotools might not be used currently for sqlite (libtool still is)…

The tarball also contains a pre-built ltmain.sh script, so libtool package installation is not needed.

Just to clarify, removing gmake from the instructions in doc/build-openbsd.md is also intentional in this pull request?

Yes, it is. CMake can work with any flavour of Make, so GNU Make is not longer a requirement.

But the document still refers to gmake, no? For example line 47 of doc/build-openbsd.md says:

0gmake -C depends NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_SQLITE=1 NO_NATPMP=1 NO_UPNP=1 NO_ZMQ=1 NO_USDT=1

Maybe gmake is installed as part of cmake, but I haven’t checked that.

Just a nit in any case.

But the document still refers to gmake, no? For example line 47 of doc/build-openbsd.md says:

0gmake -C depends NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_SQLITE=1 NO_NATPMP=1 NO_UPNP=1 NO_ZMQ=1 NO_USDT=1

The line above refers to depends/README.md, where the required build dependencies, including gmake, are suggested to be installed.

Is the intent to handle any cross-compilation to Apple platforms from non-Apple hosts, or specifically cross-compilation to macOS? Is this the same as

0CMAKE_CROSSCOMPILING AND NOT CMAKE_HOST_APPLE

?

Is the intent to handle any cross-compilation to Apple platforms from non-Apple hosts, or specifically cross-compilation to macOS?

The former.

Is this the same as

0CMAKE_CROSSCOMPILING AND NOT CMAKE_HOST_APPLE

?

In the context of a toolchain file, it is not. The CMAKE_CROSSCOMPILING variable is well-defined after a project() call, but not within a toolchain file.

From the message command docs:

The CMake command-line tool displays STATUS … messages on stdout with the message preceded by two hyphens and a space.

I’m afraid that two hyphens in every line could clutter the summary.

set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)

Why is this (-fvisibility-inlines-hidden) being added, if we don’t use it in master?

Wonder if that was it?

I don’t remember.

Looks like AC_SYS_LARGEFILE / _LARGE_FILES was never ported?

The comment in the implementation code mentions “32-bit AIX 4.2.1+, 32-bit z/OS”. Do we support those systems?

Previously benchmarks were enabled by default, right? (Edit, just noticed previous comments asking the same)

Is this why the build is so much faster now?

I can run the benchmarks from the command line, but the IDE is complaining they’re not part of the project. Is that expected?

Same is true for the fuzz tests - was hoping I could run them from the IDE now.

Edit: I see now that turning off bench was deliberate, my questions remain only about the IDE not detecting the benchmarks and fuzz even after I enable them, and running FUZZ tests from IDE, like we can run and debug other tests.

Previously benchmarks were enabled by default, right?

Right.

Is this why the build is so much faster now?

As mentioned earlier:

Regarding the part about “the default with autoconf is on” part, in the CMake working group, we decided to enable by default only the “essential” build targets that most developers build most often in their everyday work. This means, for instance, that -DBUILD_BENCH and -DBUILD_GUI are OFF by default.

I can run the benchmarks from the command line, but the IDE is complaining they’re not part of the project. Is that expected?

Is the project configured with -DBUILD_BENCH=ON?

@paplorinc

Please open an issue in https://github.com/hebasto/bitcoin/issues with detailed steps to reproduce the problem from the scratch.

I managed to make it work, I think the internal IDE setting were overwriting the ones I was setting from the command line.

For the record, with these settings the bench and fuzz projects are enabled (though no IDE assistance - i.e. run from the IDE -, but that’s a different issue):

I did open an unrelated suggestion for better error messages: https://github.com/hebasto/bitcoin/issues/306

I managed to make it work…

I consider this conversation as resolved then.

if this refers to the docker base, we could update it to:

0# Ubuntu 24.04 LTS Noble Numbat, https://wiki.ubuntu.com/Releases, EOSS in June 2029, EOL in April 2036:
1#  - CMake 3.28.3, https://packages.ubuntu.com/noble/cmake

if this refers to the docker base…

It refers to a system that users are using to build Bitcoin Core. In most cases, it will be their regular machines. However, building Bitcoin Core within a Docker container is also supported.

Ubuntu and CentOS are mentioned here as mainstream DEB and RPM-based distros. However, the new CMake-based build system is designed to work out-of-the-box on a wide range of other platforms.

Got it, so our tests are run with a different version than what we’re mentioning here, right?

CMake version can be any >= 3.22. However, CMake ensures backward compatibility using the policies. Only policies known to version 3.22 are enabled, regardless of the actual CMake version.

Not sure it makes sense, but could we have one of the docker images have this version, to expose ourselves to the documented os version as well (e.g. to catch if someone uses an old dependency, like a CMake 3.22.1 incompatibility)?

That was done for the staging branch (see .github/workflows/cmake.yml). For this PR, it is out of the scope as it is focused on the migration only. Anyway, this CI job uses Ubuntu 22.04 and CMake 3.22.1.

We still want to allow the building of Bitcoin Core on Ubuntu 22.04 using the cmake package available in the system repository.

For reference, the last time the CMake minimum required version was updated was in https://github.com/hebasto/bitcoin/pull/123.

Pretty sure there are two separate bugs here:

• The first is that BOOST_NO_CXX98_FUNCTION_BASE isn’t removed from CMAKE_REQUIRED_DEFINITIONS after this check, which means it’s incorrectly reused for the check below.

• The second is that when -DWERROR=ON is used, -Werror isn’t being passed to the check for the Boost Test header (which also hides the first bug).

I wasn’t able to run the fuzz tests with cmake (tried all mac tricks I could find here), I’m getting:

0-- Performing Test CXX_SUPPORTS__FSANITIZE_UNDEFINED_ADDRESS_FUZZER
1-- Performing Test CXX_SUPPORTS__FSANITIZE_UNDEFINED_ADDRESS_FUZZER - Success
2-- Performing Test LINKER_SUPPORTS__FSANITIZE_UNDEFINED_ADDRESS_FUZZER_a797
3-- Performing Test LINKER_SUPPORTS__FSANITIZE_UNDEFINED_ADDRESS_FUZZER_a797 - Failed
4CMake Error at CMakeLists.txt:389 (message):
5  Linker did not accept requested flags, you are missing required libraries.
6
7
8-- Configuring incomplete, errors occurred!

given:

 0% brew --prefix llvm   
 1/opt/homebrew/opt/llvm
 2
 3% clang --version               
 4Homebrew clang version 18.1.8
 5Target: arm64-apple-darwin23.5.0
 6Thread model: posix
 7InstalledDir: /opt/homebrew/opt/llvm/bin
 8
 9% clang++ --version               
10Homebrew clang version 18.1.8
11Target: arm64-apple-darwin23.5.0
12Thread model: posix
13InstalledDir: /opt/homebrew/opt/llvm/bin

Am I doing something wrong or should I open an issue for this as well?

cc @dergoegge

I wasn’t able to run the fuzz tests with cmake

Are you able to build them using Autotools?

Are you able to build them using Autotools?

Yea, the steps in fuzzing.md currently work with master, but don’t work this branch (ad2140d4d8cccec82fdad07bdc7532e202282306).

I’ve tested on macOS Monterey 12.7.6 (Intel) with Homebrew’s llvm@16. Everything works flawlessly.

Is there any way I could help here?

Mind providing full verbose build logs for both Autotools and CMake please?

The problem was that brew gcc and Xcode 15 have an duplicate lib:

ld: warning: ignoring duplicate libraries: ‘-lc++‘gs)

But since we’ve enabled fatal warnings for Mac, we’re getting:

ld: fatal warning(s) induced error (-fatal_warnings)

Based on: https://stackoverflow.com/questions/77164140/ld-warning-ignoring-duplicate-libraries-lgcc-after-the-recent-update-of-xc we should be able to work around it:

 0diff --git a/cmake/module/TryAppendLinkerFlag.cmake b/cmake/module/TryAppendLinkerFlag.cmake
 1--- a/cmake/module/TryAppendLinkerFlag.cmake	(revision ec5d1c372b20d49147813aa0392195a3642b86a1)
 2+++ b/cmake/module/TryAppendLinkerFlag.cmake	(date 1723148834055)
 3@@ -79,7 +79,7 @@
 4 if(MSVC)
 5   try_append_linker_flag("/WX" VAR working_linker_werror_flag)
 6 elseif(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
 7-  try_append_linker_flag("-Wl,-fatal_warnings" VAR working_linker_werror_flag)
 8+  try_append_linker_flag("-Wl,-no_warn_duplicate_libraries,-fatal_warnings" VAR working_linker_werror_flag) # https://github.com/orgs/Homebrew/discussions/4794#discussioncomment-7044468
 9 else()
10   try_append_linker_flag("-Wl,--fatal-warnings" VAR working_linker_werror_flag)
11 endif()

which makes building with fuzz possible:

ld: warning: ignoring duplicate libraries: ‘-lc++’, ‘../../../libleveldb.a’, ‘../../../libminisketch.a’, ‘../../libbitcoin_common.a’, ‘../../secp256k1/src/libsecp256k1.a’, ‘../../univalue/libunivalue.a’ [100%] Built target fuzz

and fuzzing can start (with the same error as the Autotools version)

% FUZZ=bech32 ./build_fuzz/src/test/fuzz/fuzz
fuzz(91171,0x2060fcc00) malloc: nano zone abandoned due to inability to reserve vm space. /opt/homebrew/opt/llvm/bin/../include/c++/v1/variant:495:12: runtime error: call to function decltype(auto) std::__1::__variant_detail::__visitation::__base::__dispatcher<0ul, 0ul>::__dispatch[abi:ne180100]<void std::__1::__variant_detail::__ctor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue»::__generic_construct[abi:ne180100]<std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1»(std::__1::__variant_detail::__ctor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue»&, std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1>&&)::’lambda’(std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1>&, auto&&)&&, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&&>(std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1>, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&&) through pointer to incorrect function type ‘void (*)((lambda at /opt/homebrew/opt/llvm/bin/../include/c++/v1/variant:814:11) &&, std::__variant_detail::__base<std::__variant_detail::_Trait::_Available, RPCArg::Optional, std::string, UniValue> &, std::__variant_detail::__base<std::__variant_detail::_Trait::_Available, RPCArg::Optional, std::string, UniValue> &&)’ variant:532: note: decltype(auto) std::__1::__variant_detail::__visitation::__base::__dispatcher<0ul, 0ul>::__dispatch[abi:ne180100]<void std::__1::__variant_detail::__ctor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue»::__generic_construct[abi:ne180100]<std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1»(std::__1::__variant_detail::__ctor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue»&, std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1>&&)::’lambda’(std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1>&, auto&&)&&, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&&>(std::__1::__variant_detail::__move_constructor<std::__1::__variant_detail::__traits<RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>, (std::__1::__variant_detail::_Trait)1>, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&, std::__1::__variant_detail::__base<(std::__1::__variant_detail::_Trait)1, RPCArg::Optional, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>, UniValue>&&) defined here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /opt/homebrew/opt/llvm/bin/../include/c++/v1/variant:495:12 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 534925934 INFO: Loaded 1 modules (1210318 inline 8-bit counters): 1210318 [0x105d56048, 0x105e7d816), INFO: Loaded 1 PC tables (1210318 PCs): 1210318 [0x105e7d818,0x1070f54f8), INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes INFO: A corpus is not provided, starting from an empty corpus #2 INITED cov: 294 ft: 294 corp: 1/1b exec/s: 0 rss: 74Mb #3 NEW cov: 294 ft: 298 corp: 2/2b lim: 4 exec/s: 0 rss: 74Mb L: 1/1 MS: 1 ChangeBit- #5 NEW cov: 295 ft: 301 corp: 3/3b lim: 4 exec/s: 0 rss: 74Mb L: 1/1 MS: 2 ShuffleBytes-ChangeBit- #6 NEW cov: 295 ft: 303 corp: 4/4b lim: 4 exec/s: 0 rss: 74Mb L: 1/1 MS: 1 ChangeBit- #7 NEW cov: 295 ft: 305 corp: 5/5b lim: 4 exec/s: 0 rss: 74Mb L: 1/1 MS: 1 ChangeBit-

The problem was that brew gcc and Xcode 15 have an duplicate lib:

Not sure, given that we aren’t using Brew GCC, or Xcode, and the machine I tested on doesn’t have either of them installed. The warning output might match, but I don’t think this is the correct explanation (and it doesn’t explain why it doesn’t happen for Autotools build).

and it doesn’t explain why it doesn’t happen for Autotools build

Autotools lack -Wl,-fatal_warnings in the following check: https://github.com/bitcoin/bitcoin/blob/24ced5274438c0185963ae1296ec7dda97ea62f1/configure.ac#L365-L375

On Arm Mac I get the same configuration problem. In the logs I’m seeing:

0ld: warning: ignoring duplicate libraries: '-lc++'
1ld: fatal warning(s) induced error (-fatal_warnings)

It works with autotools (perhaps warnings aren’t errors in the configure tests?). I’ve passed the full log to @hebasto.

@m3dwards

It works with autotools (perhaps warnings aren’t errors in the configure tests?).

See: #30454 (review)

On my macOS Sonoma 14.6.1:

0% cat test.cpp 
1int main() {}
2% /opt/homebrew/opt/llvm/bin/clang++ --version
3Homebrew clang version 18.1.8
4Target: arm64-apple-darwin23.6.0
5Thread model: posix
6InstalledDir: /opt/homebrew/opt/llvm/bin
7% /opt/homebrew/opt/llvm/bin/clang++ -fsanitize=fuzzer -o test test.cpp
8ld: warning: ignoring duplicate libraries: '-lc++'

UPD. Same for the llvm@17 package, which provides clang version 17.0.6.

UPD 2. Same for the llvm@16 package, which provides clang version 16.0.6.

Similar problem: github.com/orgs/Homebrew/discussions/4794

See: #30454 (review)

errors observed #30454 (review) are not caused by CMake

Yeah, my example in #30454 (review) was also in Autotools. The same happens with CMake in #30454 (review)

btw, is it expected that modifying TryAppendLinkerFlag.cmake (e.g. the try_append_linker_flag("-Wl,-fatal_warnings" VAR working_linker_werror_flag) line) and rerunning cmake -B build_fuzz ignores the update?

Yes, that is because the result is cached.

As an alternative workaround, I’d suggest to use an extra configuration option -DAPPEND_LDFLAGS="-Wl,-no_warn_duplicate_libraries".

Addressed in https://github.com/hebasto/bitcoin/pull/316.

Apparently, not every change invalidates the cache

My understanding is that we’re already avoiding the recompilation when the source didn’t change, but when working_linker_werror_flag changes, that’s ignored. I haven’t opened a bug report to CMake since it seems to me we can fix it ourselved, see: https://github.com/hebasto/bitcoin/pull/319

I wasn’t able to run the fuzz tests with cmake

Resolved in #30454 (comment).

Nit:

0    -DCMAKE_C_COMPILER=/usr/pkg/gcc12/bin/gcc \
1    -DCMAKE_CXX_COMPILER=/usr/pkg/gcc12/bin/g++ \

nit: slightly unrelated, but in other cases similar code blocks are annotated as either “```bash” or “```sh” which are treated a bit different in e.g. CLion:

Also note that “``` bash” is also a formatted differently than “```bash”.

Should probably be done in a different PR, though…

This PR is intended to focus solely on migration. It helps to review it a lot.

Should probably be done in a different PR, though…

I agree.

Source files were separated in two groups: fixtures and tests themselves. Both groups are sorted alphabetically.

That seemed convenient to me while I was working on this script.

I noticed that there are still a few leftover make reference in this file, and in other documentation: are we planning on updating them here or in a separate pr, e.g. when removing Autotools?

I searched for other possible make references revealed a few:

• https://github.com/bitcoin/bitcoin/blob/5ebb4063571aabd89c2d7ed6c2e70d27636efdeb/src/test/README.md?plain=1#L18-L24
• https://github.com/bitcoin/bitcoin/blob/183e2fd6b55d84829faf70ba74d3f8865807772a/src/secp256k1/doc/release-process.md?plain=1#L20-L23
• https://github.com/bitcoin/bitcoin/blob/14093d5d243f6eb9cfef721c80f92848d95032ee/doc/productivity.md?plain=1#L68
• https://github.com/bitcoin/bitcoin/blob/463356d8b8948df118eda269827ca1a6da7d3132/depends/README.md?plain=1#L99
• https://github.com/bitcoin/bitcoin/blob/d8513fe41102dcbfc05235f3b95e33eb1878f880/doc/benchmarking.md?plain=1#L16
• https://github.com/bitcoin/bitcoin/blob/fad444f6e1b1ce5c1572c773db4a9a098c7a0b96/contrib/guix/INSTALL.md?plain=1#L244-L261
• https://github.com/bitcoin/bitcoin/blob/fad444f6e1b1ce5c1572c773db4a9a098c7a0b96/contrib/guix/README.md?plain=1#L263
• https://github.com/bitcoin/bitcoin/blob/fadb06c361bbda78192d89fd06195f0aa5418c56/test/README.md?plain=1#L16
• https://github.com/bitcoin/bitcoin/blob/faeb5b59a098578b3e8c552d35b5ba02b12af14d/README.md?plain=1#L51

are we planning on updating them here or in a separate pr, e.g. when removing Autotools?

Here. Feel free to open a PR in https://github.com/hebasto/bitcoin/pulls against the cmake-staging branch. After merging, the changes will be pulled in here during the next update.

UPD. Not all mentioned cases are related to CMake migration. For instance, depends still use the GNU Make.

• https://github.com/bitcoin/bitcoin/blob/14093d5d243f6eb9cfef721c80f92848d95032ee/doc/productivity.md?plain=1#L68

See https://github.com/hebasto/bitcoin/pull/323.

Might be controversial, but other Bitcoin clones seem to split into multiple projects after their CMake migrations:

• https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/bench/CMakeLists.txt#L3
• https://github.com/bitcoin-cash-node/bitcoin-cash-node/blob/master/src/bench/CMakeLists.txt#L3
• https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/test/CMakeLists.txt#L5

Still curios about:

What are the benefits of maintaining the build system in separate projects?

I’m also curious, that’s what I’m asking basically, why did the other clones decide to do this differently.

I could only find general Modularity and Reusability/Scalability/Improved Dependency Management/Isolation of Build Configurations arguments online, but not sure any applies here, hence my question.

Might be controversial, but other Bitcoin clones seem to split into multiple projects after their CMake migrations:

• https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/bench/CMakeLists.txt#L3

It is not controversial, just broken :)

The cmake -S src/bench -B build command fails.

The cmake -S src/bench -B build command fails.

It seems to me they’re using ninja for these tasks, i.e. ninja bench-bitcoin instead of raw cmake.

The cmake -S src/bench -B build command fails.

It seems to me they’re using ninja for these tasks, i.e. ninja bench-bitcoin instead of raw cmake.

It seems this discussion has gone off topic :)

nit: alphabetic ordering?

 0diff --git a/src/crypto/CMakeLists.txt b/src/crypto/CMakeLists.txt
 1--- a/src/crypto/CMakeLists.txt	(revision 92f7fc21768b0d898655d68b5d76ff09ff71c682)
 2+++ b/src/crypto/CMakeLists.txt	(date 1723279760256)
 3@@ -4,19 +4,19 @@
 4 
 5 add_library(bitcoin_crypto STATIC EXCLUDE_FROM_ALL
 6   aes.cpp
 7-  chacha20.cpp
 8   chacha20poly1305.cpp
 9+  chacha20.cpp
10   hex_base.cpp
11   hkdf_sha256_32.cpp
12   hmac_sha256.cpp
13   hmac_sha512.cpp
14-  poly1305.cpp
15   muhash.cpp
16+  poly1305.cpp
17   ripemd160.cpp
18   sha1.cpp
19-  sha256.cpp
20-  sha256_sse4.cpp
21   sha3.cpp
22+  sha256_sse4.cpp
23+  sha256.cpp
24   sha512.cpp
25   siphash.cpp
26   ../support/cleanse.cpp

Nit, feel free to ignore these if not important:

0  rpc/spend.cpp
1  rpc/signmessage.cpp

Nit:

 0diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
 1--- a/src/CMakeLists.txt	(revision 92f7fc21768b0d898655d68b5d76ff09ff71c682)
 2+++ b/src/CMakeLists.txt	(date 1723286445028)
 3@@ -106,8 +106,8 @@
 4   addresstype.cpp
 5   base58.cpp
 6   bech32.cpp
 7-  chainparamsbase.cpp
 8   chainparams.cpp
 9+  chainparamsbase.cpp
10   coins.cpp
11   common/args.cpp
12   common/bloom.cpp
13@@ -130,18 +130,18 @@
14   key.cpp
15   key_io.cpp
16   merkleblock.cpp
17+  net_permissions.cpp
18   net_types.cpp
19   netaddress.cpp
20   netbase.cpp
21-  net_permissions.cpp
22   outputtype.cpp
23   policy/feerate.cpp
24   policy/policy.cpp
25   protocol.cpp
26   psbt.cpp
27+  rpc/external_signer.cpp
28   rpc/rawtransaction_util.cpp
29   rpc/request.cpp
30-  rpc/external_signer.cpp
31   rpc/util.cpp
32   scheduler.cpp
33   script/descriptor.cpp

Note that with 80073c75d1218759f58ceefcb41b4fbc4a3d1ecd I could right click and debug and CLion would stop at a breakpoint, but with 67b1e236334f38ec4e4d2251dbdfb790f20ed88b (adding debug-prefix-map) it won’t stop at breakpoints anymore.

But as stated in the docs, setting the target.source-map in ~/.lldbinit fixed debugging again. Or when that wasn’t working, setting “Use file name only” on the breakpoint, did.