feat(wsdb): build against one pinned aztec-packages release outside the monorepo - #25518
Open
charlielye wants to merge 1 commit into
Open
charlielye wants to merge 1 commit into
charlielye wants to merge 1 commit into
Conversation
charlielye
requested review from
iakovenkos,
ledwards2225 and
ludamad
as code owners
September 21, 2026 20:34
charlielye
force-pushed
the
cl/wsdb-pinned-deps
branch
from
September 21, 2026 21:00
b7e367e to
e915ca0
Compare
charlielye
changed the title
charlielye
force-pushed
the
cl/wsdb-pinned-deps
branch
3 times, most recently
from
September 23, 2026 12:11
895d1e8 to
4a57dfb
Compare
charlielye
force-pushed
the
cl/wsdb-decouple
branch
from
September 23, 2026 15:24
f5cb13c to
a56986c
Compare
charlielye
force-pushed
the
cl/wsdb-pinned-deps
branch
4 times, most recently
from
September 24, 2026 18:40
072e366 to
3acd786
Compare
charlielye
force-pushed
the
cl/wsdb-decouple
branch
2 times, most recently
from
September 24, 2026 19:59
dee4b34 to
f522fae
Compare
charlielye
force-pushed
the
cl/wsdb-pinned-deps
branch
2 times, most recently
from
September 24, 2026 20:06
8a2489e to
36d87bf
Compare
charlielye
force-pushed
the
cl/wsdb-pinned-deps
branch
from
September 26, 2026 10:14
36d87bf to
fcf2bf3
Compare
…he monorepo native-packages/wsdb reached out of its directory four ways: libbarretenberg.a, libenv.a and libvm2_sim.a from barretenberg's build tree, ipc-runtime's headers and archive from the same tree, ipc-codegen's generate.ts, and protocol/constants-codegen on the checked-out constants.nr. None of those paths exist once the package moves to its own repository. Everything now comes from one aztec-packages release, pinned by tag in foundation.pin (cpp/CMakeLists.txt): - barretenberg: barretenberg-static-<arch>-<os>.tar.gz from the barretenberg GitHub release of the tag, sha256-verified per platform. That archive, libbb-external.a, is self-contained (env and the vm2 stub inside) and with this change also carries world_state_reference and its bb_wsref_* C ABI, so the conformance test links it alone. wsdb links exactly that one archive: libenv.a and libvm2_sim.a were only ever needed to resolve symbols of the whole libbarretenberg.a. deps.cmake probes the archive for the poseidon2 and reference C ABIs at configure time and fails naming the pin when the release predates them. - ipc-runtime and ipc-codegen: a sparse partial clone of aztec-packages at the tag (--filter=blob:none --depth 1 --sparse, then ipc-runtime/cpp and ipc-codegen; a few MB, ~2s). ipc-runtime is add_subdirectory'd and compiled in; ipc-codegen runs from the checkout. - protocol constants: npx @aztec-foundation/constants-codegen at the tag's version, which embeds its release's constants.nr. - googletest is fetched and built here instead of borrowed from barretenberg's build. There is no monorepo path at all: the two fetches are plain FetchContent declarations, wsdb's bootstrap.sh runs them like any other consumer, and the Makefile's wsdb target no longer depends on barretenberg, ipc-runtime or ipc-codegen. The monorepo therefore builds wsdb against the pinned release, not its own HEAD, and a change wsdb needs from barretenberg or the generator reaches it by moving the pin once a release carries it. The tree benchmarks that came across from barretenberg (cpp/src/benchmark, never wired into wsdb's build) now build as wsdb_bench, and bootstrap.sh's bench_cmds runs every family at 1024 leaves into bench-out/*.bench.json, the form the repo's bench upload merges; barretenberg's own bench_cmds never ran them, so this is new coverage. The bb-header parity target is gone with the old link line: it needed a full checkout and a Tracy fetch, and the reference conformance suite already proves hash and root agreement with barretenberg end to end. ipc-codegen gains a package.json and joins the release lists so it can be published; once it is, it moves to npx like the constants and the clone shrinks to ipc-runtime. Verified: the configure sparse-clones aztec-packages and downloads the pinned nightly's archive, and the build then fails as expected because that nightly predates #24392 (no poseidon2 C ABI in the archive, and a generator without the wire-namespace aliases); with a fresh sparse clone of this branch as the source and a post-#24392 archive (FetchContent's standard FETCHCONTENT_SOURCE_DIR_<name>), ipc-runtime compiles from the clone, ipc-codegen runs from it, the constants come from npx, and all 167 tests pass. CI is red for wsdb until the first nightly after #24392, at which point foundation.pin (the tag and nothing else) moves to it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EUKia6wteDk9kZZuT2Gju
charlielye
force-pushed
the
cl/wsdb-pinned-deps
branch
from
September 26, 2026 15:28
fcf2bf3 to
bd26343
Compare
This branch has not been deployed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Stacked on #24392 (which now also carries the one-line bb change:
libbb-external.againsworld_state_referenceand itsbb_wsref_*C ABI).Audit.
lmdblibandkvdbreach only their siblinglmdblibandci3.wsdbreached out four ways: barretenberg's build tree (libbarretenberg.a,libenv.a,libvm2_sim.a, gtest), ipc-runtime's headers and archive from that tree,ipc-codegen/src/generate.ts, andprotocol/constants-codegenon the checked-outconstants.nr.Change.
foundation.pinis one tag;cpp/CMakeLists.txtfetches everything from that release with two plainFetchContentdeclarations. There is no monorepo path:bootstrap.shbuilds wsdb exactly as any other consumer would, and the Makefile'swsdbtarget no longer depends onbb-cpp-native,ipc-runtimeoripc-codegen.bb_poseidon2_hash*;bb_wsref_*for the conformance test)barretenberg-static-<arch>-<os>.tar.gzfrom the barretenberg GitHub release of the tagipc-runtime/cppandipc-codegen(~5 MB, ~2 s)npx @aztec-foundation/constants-codegen@<tag version>(embeds its release'sconstants.nr)libenv.aandlibvm2_sim.aonly ever resolved symbols of the wholelibbarretenberg.a.package.jsonand joins the release lists so it can be published. googletest is built in wsdb's own tree.Verified. Against the pinned nightly the sparse clone and the archive download both work; the build then fails as expected because that nightly predates #24392. With a fresh sparse clone of this branch as the source and a post-#24392 archive (FetchContent's standard
FETCHCONTENT_SOURCE_DIR_<name>): 167 tests.Sequencing. wsdb is red in CI until the first nightly after #24392 merges; then
foundation.pinmoves to that tag and this PR goes green. The monorepo builds wsdb against the pin from then on, not its own HEAD.🤖 Generated with Claude Code
https://claude.ai/code/session_012EUKia6wteDk9kZZuT2Gju