To properly allow tekton benchmark pipelines to clean data, explicitly output the name of the test. Also using heaptrack compiled from source, avoid issues from heaptrack gui and profile creation procedures.
Example:
```
./qa/zcash/performance-measurements.sh memory createsaplingspend | tail -n 7 | python ./mem_metrics.py
```
Cannot parse because the profile is ONLY setup after runtime
Fix:
```
./qa/zcash/performance-measurements.sh memory createsaplingspend
(performance_measurements has -o to output createsaplingspend.gz)
heaptrack -a createsaplingspend.gz | tail -n 7 | python ./mem_metrics.py
```
Excess Orchard actions would always report “Orchard actions” rather than the specific “Orchard
inputs” or “Orchard outputs” when creating a tx. “Actions” wasn’t incorrect per se, but it was only
a bug in a `switch` that prevented a more helpful message from being presented to the user.
- `zcash/cache.{cpp,h}` is only directly used by the `cxx` bridge, so we
move them into `libcxxbridge`.
- `libbitcoin_script` depends on `libcxxbridge`, so we add the sources
for the latter to `libzcash_script`.
- `libbitcoin_script` depends on the non-`cxx` Rust FFI, so we add
`librustzcash` as a dependency.
This enables us to add it to `*_LIBADD` lists in addition to the
`*_LDADD` lists it was already present in.
Co-authored-by: Daira Emma Hopwood <daira@jacaranda.org>
A single consensus module made sense for upstream Bitcoin Core, but
after we refactored `libbitcoinconsensus` into `libzcash_script` in
zcash/zcash#4966, we need to distinguish between the two.
Some extra bytes in libconsensus to get all the crypto (except for signing, which is in the common module) below the libconsensus future independent repo (that has libsecp256k1 as a subtree).
hmac_sha256.o seems to be the only thing libbitcoinconsensus doesn't depend on from crypto, some more bytes for the final libconsensus: I'm not personally worried.
(cherry picked from commit bitcoin/bitcoin@cf82d05dd4)
(cherry picked from commit bitcoin/bitcoin@a3d5eec546)
Zcash: Adapted to our local changes. We don't move `uint256.{cpp,h}`
because `uint256::SetHex` is depended on by `zcash-cli` via other code
in `libbitcoin_util`.
- `-Werror` is now controlled by `--enable-werror` as it was before the previous
commit, but now it defaults to `yes`
- overriding `CXXFLAGS` no longer prevents warnings from being enabled (prior to
the previous commit, configure was set up to enable certain warnings (`-Wall`, `-Wextra`, etc.),
but they were never actually used, because we always had `CXXFLAGS` overridden
We also no longer `AC_CHECK_…` individual warning flags, for a few reasons
- we know the compiler that will be used (with a few variations),
- the pivot to opt-out makes it harder to consider flags in isolation,
- there are a lot of flags now (almost 200), and
- they will be changing rapidly in the short term (~150 will go away soon).
This is presumably a transitive `include` discrepancy. I.e., there is some other `std` header that
has `#include <variant>` etc. in Clang 15 (our usual compiler) but doesn’t have it in Clang 13 (our
macOS compiler).
This check ensured that PR branches were based on a recent-enough master to work
with current Tekton builds. This check is now performed on the Tekton side
(Electric-Coin-Company/infrastructure#1613), where it more correctly belongs (as
this is effectively tracking Tekton’s dependency on zcash/zcash).
Marshall Gaucher
Daira Hopwood
Kris Nuttycombe
Greg Pfeil
Jack Grigg
Jorge Timón
Greg Pfeil