bitcoin#27314 has been backported in this PR as bitcoin#25838 (backported in dash#6384) broke Clang depends builds and this PR introduces Clang depends builds in CI.
Support for multiprocess builds were enabled proper in dash#6143 but unfortunately, the configuration params for multiprocess builds were not processed by CI as the build variant was not added to matrix.sh (source). This is evident by comparing two variants with Boost::Process enablement (--with-boost-process), linux64_fuzz (source) and linux64_multiprocess (source).
Looking at a develop (6a51ab271dd5b1b839d754337abbf58a99cbdd21) build, the fuzz build has it enabled (source) while the multiprocess build doesn't (source) despite both scripts having the enablement argument.
bitcoin#28954 has been backported to fix a problem associated with multiprocess runs (build)
The fuzz build will continue to use GCC-built depends instead of Clang-built depends as originally planned, as Clang-built depends are multiprocess-enabled and currently multiprocess and fuzz don't play nice together (see upstream build failure for example, source, corresponding with local failure, source).
Clang has been bumped to 18 in anticipation of bitcoin#30201, which will drop (native_llvm, formerly known as native_clang) and mandate the presence of Clang 18 or higher for cross-compilation.
The version attribute in the develop container's docker-compose.yml has been dropped as the attribute has been deprecated in the compose spec (source).
To avoid LLDB's "personality set failed: Operation not permitted" error caused by its attempt at disabling ASLR for debugging (source), the container will now operate under relaxed restrictions (seccomp=unconfined). As disabling ASLR is valuable when debugging and the container isn't used by CI but is meant for individual developers, we have opted to relax restrictions instead of skipping ASLR disablement.
This does not affect CI as these relaxations are defined in the docker-compose.yml of the develop container, which inherits from the CI container but is a container of its own.
As DEP_OPTS is a new parameter that could require rebuilding depends, it needs to be incorporated into the cache key. The simplest way to do it is to append the hash of the file that defines DEP_OPTS (build.yml) to the cache key. This comes with the drawback that any change to build.yml could result in a cache miss due to a changed hash.
This has been mitigated by appending the hash of DEP_OPT's value instead. As GitHub doesn't make this easy, it has to be done in a prior "Determine params" step.
This was taken as an opportunity to separate the matrix configuration out to matrix.json and use jq to interpret it. We can use jq to query values (dep_opts) meant for one matrix (deps) using a value (depends_name) from the other matrix (src).
The above setup also removes having to mention host in both matrices as the value of host is taken by the second matrix (src) by fetching it from the array of the first matrix (deps) with matching depends_name.
Breaking Changes
None expected
Checklist
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas (note: N/A)
[x] I have added or updated relevant unit/integration/functional/e2e tests (note: N/A)
[x] I have made corresponding changes to the documentation (note: N/A)
[x] I have assigned this pull request to a milestone (for repository code-owners and collaborators only)
Additional Information
Depends on https://github.com/dashpay/dash/pull/6406
Dependency for https://github.com/dashpay/dash/pull/6387
bitcoin#27314 has been backported in this PR as bitcoin#25838 (backported in dash#6384) broke Clang depends builds and this PR introduces Clang depends builds in CI.
Support for multiprocess builds were enabled proper in dash#6143 but unfortunately, the configuration params for multiprocess builds were not processed by CI as the build variant was not added to
matrix.sh
(source). This is evident by comparing two variants with Boost::Process enablement (--with-boost-process
),linux64_fuzz
(source) andlinux64_multiprocess
(source).Looking at a
develop
(6a51ab271dd5b1b839d754337abbf58a99cbdd21) build, the fuzz build has it enabled (source) while the multiprocess build doesn't (source) despite both scripts having the enablement argument.bitcoin#28954 has been backported to fix a problem associated with multiprocess runs (build)
The fuzz build will continue to use GCC-built
depends
instead of Clang-builtdepends
as originally planned, as Clang-builtdepends
are multiprocess-enabled and currently multiprocess and fuzz don't play nice together (see upstream build failure for example, source, corresponding with local failure, source).Clang has been bumped to 18 in anticipation of bitcoin#30201, which will drop (
native_llvm
, formerly known asnative_clang
) and mandate the presence of Clang 18 or higher for cross-compilation.The
version
attribute in thedevelop
container'sdocker-compose.yml
has been dropped as the attribute has been deprecated in the compose spec (source).To avoid LLDB's "personality set failed: Operation not permitted" error caused by its attempt at disabling ASLR for debugging (source), the container will now operate under relaxed restrictions (
seccomp=unconfined
). As disabling ASLR is valuable when debugging and the container isn't used by CI but is meant for individual developers, we have opted to relax restrictions instead of skipping ASLR disablement.This does not affect CI as these relaxations are defined in the
docker-compose.yml
of thedevelop
container, which inherits from the CI container but is a container of its own.As
DEP_OPTS
is a new parameter that could require rebuilding depends, it needs to be incorporated into the cache key. The simplest way to do it is to append the hash of the file that definesDEP_OPTS
(build.yml
) to the cache key. This comes with the drawback that any change tobuild.yml
could result in a cache miss due to a changed hash.This has been mitigated by appending the hash of
DEP_OPT
's value instead. As GitHub doesn't make this easy, it has to be done in a prior "Determine params" step.matrix.json
and usejq
to interpret it. We can usejq
to query values (dep_opts
) meant for one matrix (deps
) using a value (depends_name
) from the other matrix (src
).host
in both matrices as the value ofhost
is taken by the second matrix (src
) by fetching it from the array of the first matrix (deps
) with matchingdepends_name
.Breaking Changes
None expected
Checklist