feat: devbox

[charlielye]

This introduces a base build image in ./build-images. The idea is that this image contains a complete environment to bootstrap aztec-packages. It's available for both x86 and arm, and thus can be used to have a stable and consistent development environment on all operating systems that have docker installed.

The Dockerfile is a multi-stage image with 3 interesting targets:

• build: The base build image - this can be used by CI to build any part of the project. It contains just the tools needed to successfully bootstrap.
• devbox: Extends build and includes all sorts of useful developer tools. This container can be run independently via a ./build-images/run.sh script. Vscode can launch it via it's "Dev Containers" plugin, or github/vscode can launch it within codespaces, the configuration is at .devcontainer/dev/devcontainer.json.
• sysbox: Is similar to devbox but is designed to be run using nestybox's sysbox runtime, like internal aztec developers use on mainframe.

An important thing to note, is that this approach removes all toolchain installations from bootstrap scripts, as it's expected for the right things to be available in your PATH (or in the case of wasi-sdk, at /opt/wasi-sdk). The bootstrap.sh script now checks all toolchains are available and the right version at start. You can also run this command:

% ./bootstrap.sh check
Toolchains look good! 🎉

If there's an issue, a hint is provided on how to resolve, but the engineer is encouraged to just use the dev container.

What's currently checked for:

• Utils: jq, parallel, awk, git, curl.
• cmake min 3.24.
• clang-16.
• Rust 1.74.
• Wasi SDK 22 at /opt/wasi-sdk.
• forge and anvil at commit de33b6a.
• node min 18.19.
• yarn and solhint.

Aztec internal engineers who use sysbox on mainframe, should run a sudo halt at their convenience, wait for the box to restart, and they should have a setup that passes the above check. If somethings wrong, you may have some custom configuration in your home dot files that needs removing. Otherwise contact me.

Your hostkey to your sysbox may have changed! Get your IP from ~/.ssh/config and do an e.g.

ssh-keygen -R 173.26.1.1

Other notable changes:

• wasi-sdk is now version 22.0. This means we have a single sdk for both threaded and unthreaded wasms (they still need to be built independently however. TODO: Investigate if we can build once and link twice). It's expected to be installed at /opt/wasi-sdk.
• Ensured we're using version 16 of both clangd and clang-format. We should always be explicit about the version we're using. We should probably upgrade to clang/d/format 18 soon as that's what's distributed in ubuntu noble, and is also what the wasi-sdk uses.
• Update Earthly builds to use noble.
• Some cpp files formatting change with the shift from 15 to 16.
• Removed the parallel_for moody implementation. Had to update various bits of threading code to be properly ignored when building non threaded wasm. Maybe we can just always build the threaded wasm, and just link it twice with shared memory enable/disabled? Not sure.
• When running the dev container on a mac, with aztec-packages mounted from the host filesystem, there is a known bug around incremental rust builds, and fractional file modification timestamps. A script runs after building noir-repo to normalise these timestamps, if it's detected that the host is a mac.
• Purge a load of unneeded stuff when building aztec prod image, to reduce container size. We do similar for end-to-end tests because they need to be serialized from Earthly to Docker and that's currently slow.
• Simplified some end-to-end Earthly config.
• Removed all test specific timeouts in favour of just launching jest with a 5m test timeout.

[ludamad]

Why not rely on llvm strip being in path?

[charlielye]

It's not in PATH as wasi-sdk bins don't have unique prefixes.
Cross compilers usually might be named like wasi-wasm-clang++ or someting. Maybe that could be fixed in the wasi build? Then we could add wasi to PATH.

[ludamad]

I still think we'll avoid a lot of practical headache publishing this image

[charlielye]

I intend to publish (in fact have already published the wasi-sdk part). But right now the only issue should be cold start?