allyourcodebase

allyourcodebase is a GitHub organization whose repositories do one thing: give an existing C or C++ project a build.zig so it can be built, and cross-compiled, with the zig toolchain. The stated purpose is half convenience for Zig users and half demonstration for upstream maintainers — a working example of what a build.zig for their project looks like, sitting there ready to be taken.

The trade it proposes

The pitch to a maintainer is a dependency swap: add a dependency on Zig, remove several others.

Make, CMake, autoconf and the pile of bash, batch and PowerShell scripts around them go away, because the Zig build system covers what they do across every supported platform. Clang goes away, because Zig bundles a full Clang. The system package manager goes away, because Zig can fetch and build dependencies packaged for it. Docker and CI matrix jobs go away, because Zig cross-compiles C, C++ and Zig, which reduces making a release to a single zig build release step — the org points at superhtml's build.zig as the reference implementation of that step.

The general form of the claim is that Zig removes the dependency on system-wide settings while leaving opt-in available where you want it.

Two packaging strategies

The preferred one is to add the upstream project as a dependency in build.zig.zon and keep only the build.zig in the allyourcodebase repo. Upstream source stays pristine, and a maintainer adopting the work needs exactly two files.

The fallback is to fork the upstream project outright, add the Zig build scripts, optionally delete the old build system, and patch the source where necessary. Patching is usually not needed for compilation; where it earns its keep is making build steps behave under a build cache. The example given is a project-specific build tool — an asset processor or image optimizer — that hardcodes its output path to the working directory, changed to accept an output path as an argument so Zig's cache can place it.

Contributors are told to use the first strategy and only reach for the second when the source genuinely needs patching, or when they intend to clean up all the other build scripts and fix the intermediate steps properly.

Upstreaming, and the condition attached

Maintainers are explicitly free to take everything from these repos. If they do, the org asks to be told via an issue so the downstream repo can be archived and point at upstream instead.

There is one condition on archiving, and it is the more interesting rule: the upstream integration must not add more system dependencies than the packaged version had. If allyourcodebase's build gets zstd from allyourcodebase/zstd, the upstream version has to either keep doing that or use Zig's optional system library integration so the choice is the user's. Otherwise the fork stays alive and maintained in parallel. The point is to stop an "upstreamed" build from quietly reintroducing the system-package dependency the packaging existed to remove.

Contributing a repo

Access is granted by asking kristoff (Loris Cro). The checklist for a new package:

1. A license on your own build.zig, at least as permissive as the upstream project's — MIT is the always-safe answer.
2. Package the C/C++ project and nothing else. No Zig bindings; those belong in a repo of your own.
3. Target the latest tagged Zig release.
4. Use the pristine-tarball strategy unless patching or build-step cleanup forces the fork.
5. A CI job proving zig build succeeds — the AFLplusplus script is offered as a template.
6. Willingness to do occasional maintenance when upstream releases a new version.

Tag the repo (zig, zig-package) for discoverability.

The standing cost

Rules 3 and 6 are where the ongoing work lives, and they point at two moving targets rather than one. Each package has to track its upstream project's releases, and all of them have to track Zig's, because the build system API is not stable — returning-to-zig records the expectation that 0.17 breaks every project's build system, and each such release is a sweep across every repo in the organization. How well that sweep goes depends on individual volunteers still being interested, which rule 6 asks for but nothing enforces. On watchlist for that reason: the idea is sound and the failure mode is quiet bit-rot in the long tail of packages rather than a visible abandonment.

Worth pairing with zig-incremental-compilation, which is the other half of the same argument for adopting the toolchain — the build system is the part you interact with, and the compiler underneath is where the iteration-speed payoff shows up.

Organization: https://github.com/allyourcodebase. Licensing is per repository, with the org rule setting a floor of "at least as permissive as upstream"; star counts likewise live on the individual package repos rather than the org.