I recently wanted to “hack on the standard library”, as titled in @matklad‘s mini-reference. But I had a little trouble with a couple of steps, and wanted to align more with core instructions in the ziglang readme, so went this route… (critical pre-notes: 0.16/master, here, and via the newer “sans LLVM” route):
# 1) fork ziglang/zig to "myown" (sub in below), then...
git clone git@codeberg.org:myown/zig.git
cd zig
git remote add upstream https://codeberg.org/ziglang/zig.git
# 2) instead of curling the stage-3 tarball, bootsrap...
cc -o bootstrap bootstrap.c
./bootstrap
# 3) use the new zig2 to build (stage-3) zig3...
./zig2 build -p stage3
# (that fails doctests, but takes very little time to produce ./stage3/bin/zig)
# 4) this may be the beginning of a repeat cycle where upstream changes need periodic pulling:
git pull
# (this may also be where it's time to checkout to a feature branch...)
git checkout -b my-cool-feature
# 5) build stage4, including changes you may have made in lib/...
./stage3/bin/zig build -p stage4 -Dno-lib
# Rinse, lather, and repeat steps 4 and 5; use standard git add/commit/push for changes made in lib/, and, potentially, create PRs from there, back in codeberg
The result, after step 5, is a ./stage4/bin/zig which includes changes made to ./lib source. Consider running the whole test suite:
stage4/bin/zig build test
…but note that this can take an hour; follow the testing section in the main ziglang/zig README.
Some of the above also comes from “Editing Source Code” in the main ziglang/zig README.
(BONUS for step 5: in theory, use --watch -fincremental for instant rebuilds upon file-saves… but this didn’t seem to track changes in lib/std as I thought it would…)
Please critique and offer improvements or advice where I’ve gone astray.