Add bitcoin-{node,gui} to release binaries for IPC #31802
Draft
+6,126
−98
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31802. ReviewsSee the guideline for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
This was referenced Feb 5, 2025
This was referenced Feb 5, 2025
Sjors
force-pushed
the
2025/02/ipc-yea
branch
2 times, most recently
from
ef1e5b0 to
527a77e
Compare
|
Some chatter from IRC: |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
Sjors
force-pushed
the
2025/02/ipc-yea
branch
2 times, most recently
from
f43ff56 to
63dffe1
Compare
This was referenced Feb 14, 2025
Sjors
force-pushed
the
2025/02/ipc-yea
branch
from
63dffe1 to
1cb3ff9
Compare
This was referenced Mar 13, 2025
git-subtree-dir: src/ipc/libmultiprocess git-subtree-split: f35df6bdc536b068597559d4ab470dab9cff7cfc
Rename WITH_MULTIPROCESS to ENABLE_IPC, because ENABLE_IPC is a more accurate name for the feature. It controls whether the src/ipc/ directory is built and whether IPC features like -ipcbind, -ipcconnect, and -ipcfd are available. It does NOT currently enable multiprocess features which are implemented in bitcoin#10102 building on top of the IPC features. It will also no longer (as of the next commit), control whether a find_package call is made so the "WITH_" prefix is also inappropriate. -BEGIN VERIFY SCRIPT- git grep -l WITH_MULTIPROCESS | xargs sed -i s/WITH_MULTIPROCESS/ENABLE_IPC/g -END VERIFY SCRIPT-
When ENABLE_IPC option is on, build with libmultiprocess subtree and `add_subdirectory(src/ipc/libmultiprocess)` instead of external package and `find_package(Libmultiprocess)` by default. Behavior can be toggled with `WITH_EXTERNAL_LIBMULTIPROCESS` option. Using a subtree should be more convenient for most bitcoin developers, but using an external package is more convenient for developing in the libmultiprocess repository. The `WITH_EXTERNAL_LIBMULTIPROCESS` option is also used to avoid needing to changing the depends build here. But in later commits, the depends build is switched to use the add_subdirectory build as well. Co-authored-by: Cory Fields <[email protected]>
This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, several jobs fail due to the mptest executable not being built by default, as reported bitcoin#30975 (comment)
This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, the "macOS 14 native no depends job" fails due to warnings in boost headers treated as errors, reported in bitcoin#30975 (comment) and bitcoin-core/libmultiprocess#138
This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, clang-tidy job fails due to missing generated example files as reported bitcoin#30975 (comment) Different fixes were suggested bitcoin#30975 (comment) and bitcoin#30975 (comment) Co-authored-by: Hennadii Stepanov <[email protected]>
This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. Specifically this makes it possible to use the BUILD_FOR_FUZZING and ENABLE_IPC options together easily. The change just updates the cmake build so when -DSANITIZERS=fuzzer is specified, the fuzz test binary is built with -fsanitize=fuzzer (so it can use libFuzzer's main function), and libraries are built with -fsanitize=fuzzer-no-link (so they can be linked into other executables with their own main functions). Previously when -DSANITIZERS=fuzzer was specified, -fsanitize=fuzzer was applied to ALL libraries and executables. This was inappropriate because it made it impossible to build any executables other than the fuzz test executable without triggering link errors: - "multiple definition of `main'" - "undefined reference to `LLVMFuzzerTestOneInput'" if they depended on any libraries instrumented for fuzzing. This was especially a problem when the ENABLE_IPC option was set because the mpgen code generator could not be built, so nothing else that depended on generated sources including the fuzz test binary could be built either.
Co-authored-by: Cory Fields <[email protected]>
Without this change linter produces errors about: - Use of std::filesystem the libmultiprocess example program. - Use of locale-dependent functions in example program, in the build time code generator, and in the runtime library for debug logging. - Include guards not beginning with BITCOIN_
Move parts of the int_get_build_id into a new int_get_build_properties function. There is no change in behavior. This just organizes assignments better so some build properties can be used to help compute build ids in the next commit.
With newly introduced libmultiprocess subtree, there's no need for depends system to download and track changes to the upstream repository. Note that adding the libmultiprocess subtree does not allow dropping libmultiprocess packages from the depends build, because libmultiprocess includes a code generation tool called mpgen, and in cross-compiled builds, bitcoin core's cmake build system doesn't have access to a native toolchain and can't build mpgen itself, so the depends system (or the native environment if not using depends) needs to supply it.
Co-authored-by: Hennadii Stepanov <[email protected]>
Except: 1. i686, DEBUG (changed to "no multiprocess") 2. Windows due to lack of support
Install capnp where needed. The bitcoin-node binary is built on all platforms which have multiprocess enabled, but for functional tests it's only used in the macOS native (no depends) and CentOS native (depends) jobs.
Except for Windows and OpenBSD.
This was referenced Mar 18, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Have depends make libmultiprocess by default, which has the effect of including it in the release binaries. Except for Windows and OpenBSD which are not supported yet, the latter due to a fairly trivial upstream issue.
The initial main use case is to enable experimental support for the Mining IPC interface. A working example of a Stratum v2 Template Provider client using this interface can be found here: Sjors#48.
Additionally the
bitcoin-nodeandbitcoin-guiare added toMaintenance.cmake.Builds on #30975 (which originally tried to do this) and #31741.
See #31756 for discussion of when this should happen. See also #31098 for any remaining issues specific to the Mining interface. Will keep this draft for now.
Guix hashes: