Comparison with other tools¶
This document aims to highlight the differences between zb and other tools.
Bazel¶
Bazel and zb share the very similar goal to build software in a reproducible manner. zb mostly differs in how it achieves the goal:
Bazel requires reworking the build graph to be written in terms of Bazel rules. This typically requires surrounding tooling (IDEs, etc.) to be Bazel-aware. Setting up a zb build process is less involved because it leverages existing build tooling appropriate for each ecosystem. You can easily run
zb derivation envon any build step to obtain a.envfile to emulate the build environment.zb uses Lua instead of Starlark, Bazel’s bespoke Python-like language. zb uses Lua to leverage existing learning resources for Lua.
Bazel has different APIs for creating rules and macros. zb does not draw such a distinction: all build steps invoke a single program. zb functions can be written to automate creation of build steps.
zb build artifacts have a consistent file path across hosts and can have dependencies on other build artifacts. This eliminates the need for runfiles and makes dynamic linking simpler.
Nix¶
Many of the techniques in zb were pioneered by the Nix package manager. zb is built on the principles in the original paper by Eelco Dolstra, but differs in some key ways:
zb is focused on building software, not managing packages. We don’t anticipate a large, central package repository for zb nor a Linux distribution. There’s a lot of overlap in dependency management, but the audience and affordances differ in subtle ways.
zb deliberately focuses on broad usability. For example, zb supports Windows and uses Lua instead of a domain-specific language.
zb uses content-addressed derivations. This is a long-standing experimental feature in Nix, whereas zb does not even support Nix’s default “input-addressed” mode. This was chosen to simplify the architecture, enable build optimizations, and prevent build artifact corruption.
