|
| 1 | +# Comparison with other tools |
| 2 | + |
| 3 | +This document aims to highlight the differences between zb and other tools. |
| 4 | + |
| 5 | +(bazel)= |
| 6 | +## Bazel |
| 7 | + |
| 8 | +Bazel and zb share the very similar goal to build software in a reproducible manner. |
| 9 | +zb mostly differs in how it achieves the goal: |
| 10 | + |
| 11 | +- Bazel requires reworking the build graph to be written in terms of [Bazel rules][]. |
| 12 | + This typically requires surrounding tooling (IDEs, etc.) to be Bazel-aware. |
| 13 | + Setting up a zb build process is less involved |
| 14 | + because it leverages existing build tooling appropriate for each ecosystem. |
| 15 | + You can easily run `zb derivation env` on any build step |
| 16 | + to obtain a `.env` file to emulate the build environment. |
| 17 | +- zb uses Lua instead of [Starlark][], Bazel's bespoke Python-like language. |
| 18 | + zb uses Lua to leverage existing learning resources for Lua. |
| 19 | +- Bazel has different APIs for [creating rules][Bazel rules API] and [macros][Bazel macros]. |
| 20 | + zb does not draw such a distinction: |
| 21 | + all build steps invoke a single program. |
| 22 | + zb functions can be written to automate creation of build steps. |
| 23 | +- zb build artifacts have a consistent file path across hosts |
| 24 | + and can have dependencies on other build artifacts. |
| 25 | + This eliminates the need for [runfiles][] |
| 26 | + and makes dynamic linking simpler. |
| 27 | + |
| 28 | +[Bazel rules]: https://bazel.build/rules |
| 29 | +[Bazel rules API]: https://bazel.build/extending/rules |
| 30 | +[Bazel macros]: https://bazel.build/extending/macros |
| 31 | +[runfiles]: https://bazel.build/reference/be/common-definitions#common.data |
| 32 | +[Starlark]: https://bazel.build/rules/language |
| 33 | + |
| 34 | +(nix)= |
| 35 | +## Nix |
| 36 | + |
| 37 | +Many of the techniques in zb were pioneered by the [Nix][] package manager. |
| 38 | +zb is built on the principles in the [original paper by Eelco Dolstra][@dolstra_purely_2006], |
| 39 | +but differs in some key ways: |
| 40 | + |
| 41 | +- zb is focused on building software, not managing packages. |
| 42 | + We don't anticipate a large, central package repository for zb |
| 43 | + nor a Linux distribution. |
| 44 | + There's a lot of overlap in dependency management, |
| 45 | + but the audience and affordances differ in subtle ways. |
| 46 | +- zb deliberately focuses on broad usability. |
| 47 | + For example, zb supports Windows |
| 48 | + and uses Lua instead of a domain-specific language. |
| 49 | +- zb uses content-addressed derivations. |
| 50 | + This is a long-standing [experimental feature in Nix][ca-derivations], |
| 51 | + whereas zb does not even support Nix's default "input-addressed" mode. |
| 52 | + This was chosen to simplify the architecture, |
| 53 | + enable build optimizations, |
| 54 | + and prevent build artifact corruption. |
| 55 | + |
| 56 | +[ca-derivations]: https://nix.dev/manual/nix/2.24/development/experimental-features.html#xp-feature-ca-derivations |
| 57 | +[@dolstra_purely_2006]: https://edolstra.github.io/pubs/phd-thesis.pdf |
| 58 | +[Nix]: https://nixos.org/ |
0 commit comments