...are belong to us, but we'd be delighted to give them back!

We package C/C++ projects for theZig build system so that you can reliablycompile (and cross-compile!) them with ease.

This both provides convenience for users of the Zig compiler toolchain andalso showcases to C/C++ project maintainers what abuild.zig file fortheir project looks like.

As a general answer, we add a dependency on Zig to your project but in exchange we remove a dependency on:

• Make / GNUMake / CMake / autoconf / bash scripts / batch scripts / powershell scripts: Zig is a complete build system that works on all supported platforms and can doeverything those other tools do.
• Clang: Zig is a full compiler toolchain and happens to also bundle all ofclang.
• The system package manager: Zig is also a package manager and can download and build dependencies packaged for it, if you want it to.
• Docker / CI matrix jobs: Zig can cross-compile C/C++/Zig code, making a release is as simple as runningzig build release.

More in general Zig removes all dependency on system-wide settings, while still leaving you the ability to opt-in when you need to.

If you're the maintainer of a project packaged by us and decide that youwant to upgrade your build pipeline, then you are free to upstream everythingyou need from our repos.

If you decide to do so, please let us know by opening an Issue so that we canarchive our repo and point people to your upstream. Feel also free to use our repos' Issuessection to ask questions about how to integrate everything correctly in your project(say, maybe because we didn't implement a secondary build step for example).

One last thing to note: for us to be able to archive our repository, your integrationof ourbuild.zig must not add more system dependencies than our version. So, for example,if our packaged version is able to depend on zstd viaallyourcodebase/zstd,then we kindly ask that you either keep depending on it (until itsbuild.zig gets upstreamed)or take advantage ofSystem Library Integrationto give the user the choice.

That said, you're obviously welcome to upstream any build code as you see fit even ifyou don't plan to keep depending on other packages via the Zig build system. We'll still be happyto help you in this case, of course, but we'll also keep maintaining our downstream fork.

We use two main strategies:

1. Add the upstream project as a dependency (inbuild.zig.zon) and define the correspondingbuild.zig script in our repo.
2. Fork the upstream project (optionally remove other -- now useless :^) -- build scripts), add Zig build scripts to it and apply any necessary patch to the original project. This last part is usually not necessary but some build steps might benefit by making some config scripts and such more amenable to be used by the Zig build system. One example of that would be to have scripts accept an output path as an argument instead of hardcoding where their output goes (this is very useful to integrate properly with Zig build cache).

If you're a maintainer of the upstream project, (1) shows clearly that you will only need two files (build.zig,build.zig.zon) but it will be up to you to clean up all other build scripts and possibly improve our Zig build script as described above, while (2) will require you to be a bit more careful when upstreaming the work but everything will have been done for you more thoroughly (although you still have the option to just take the Zig build script files and manually review how to integrate them in your upstream project).

Pingkristoff and ask to be added to the organization.

Here are some ground rules to be able to contribute a repo:

1. Your repo must have a license for your code (the newbuild.zig file) and it must be at least as permissive as the original project's license (to make things simple you can just use MIT and will never be wrong).
2. Your repo must package the original C/C++ project without adding extra Zig-specific stuff like bindings, for example.
   You are welcome to put bindings in a separate repo owned directly by you.
3. You must target the latest tagged version of Zig.
4. When porting the original project, you should use the first strategy (build.zig + pristine tarball) and only turn to the second one (forking the full project) if:
   • You need to patch the original source code for it to build correctly
   • You are going to clean up all other build scripts and improve how intermediate steps of the build process work
     • An example of this last point would be changing project-specific build tools (eg asset processing tools, like image optimizers) that hardcode an output path (usually cwd)to instead accept an output argument in order to make them better citizens of the Zig build (eco)system.
5. You must add a CI job that guaranteeszig build succeeds, for example, you can copy the script fromallyourcodebase/AFLplusplus.
6. You must have interest in doing occasional maintainership work to update your build script when a new version of the upstream project is released.

Once you're done with the checklist above, please give your repo an appropriate set of tags for ease of discoverability (egzig,zig-package).

Repositories