# Build targets

Stream uses Zig 0.17.1. Production builds use `ReleaseSafe`, baseline CPU
features, and `x86_64-linux-gnu`. Keep compiler versions synchronized across
`build.zig.zon`, `tools/loadgen/build.zig.zon`, CI, Docker, and the admission host.

```sh
zig build -Doptimize=ReleaseSafe -Dcpu=baseline -Dtarget=x86_64-linux-gnu
zig build -Doptimize=ReleaseSafe -Dcpu=baseline -Dtarget=aarch64-linux-gnu
```

A successful cross-build establishes compilation, not runtime support. The
serialized admission gate executes Linux x86-64 behavior, storage recovery,
and protocol contracts before production deployment. ARM64 requires its own
runtime qualification before deployment. macOS ARM64 is the development host.

Build probes for the destination CPU too. A native HeavyPad loadgen build
uses instructions unavailable on the production host and fails before connecting.
For a probe that will be copied to production:

```sh
cd tools/loadgen
zig build -Doptimize=ReleaseSafe -Dcpu=baseline -Dtarget=x86_64-linux-gnu
```

## WebAssembly

`zig build -Dtarget=wasm32-wasi` currently fails while configuring RocksDB:
its build supports Linux and macOS, not WASI. The full service also depends
on native threading, sockets, filesystem persistence, C++, and telemetry.
It is not currently a WebAssembly deployment target.

Zeldi separates its native host from explicitly built WebAssembly cells.
The transferable pattern is to expose a narrow portable codec/inspection
module and test it independently. Compiling a dependency or an unused module
to WebAssembly does not prove the Stream server works there. Extracting that
surface is separate work, not part of a dependency maintenance release.

## Release metadata

The binary defaults to the version in `build.zig.zon`; `-Dversion` can override
it. Release images should carry the commit date through `-Dbuild-date` and the
source SHA through the existing build-info options. Use `stream version` and
`stream_build_info` to verify the deployed artifact.