Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/pg83/ix/llms.txt

Use this file to discover all available pages before exploring further.

The die/ directory under pkgs/ contains all base build-system templates. Every ix.sh starts with {% extends %} pointing at exactly one of these templates, inheriting the complete build pipeline — dependency wiring, compiler flag injection, install-time cleanup, and cross-compilation support — for that build system. You only override what differs from the default behavior.

​
Template Selection Table

Choose the template that matches the upstream build system. When unsure, look for an existing package in pkgs/ that uses a similar build system and copy its template choice.
Template{% extends … %}When to use
GNU Make//die/c/make.shmake && make install, no configure script
Autoconf//die/c/configure.sh./configure && make && make install
Autotools//die/c/autohell.shautoconf + automake, autoreconf needed
Autotools (rehell)//die/c/autorehell.shAlways prefer over autohell.sh
CMake//die/c/cmake.shCMake
Meson//die/c/meson.shMeson
Ninja (raw)//die/c/ninja.shNinja without CMake or Meson
WAF//die/c/waf.shWAF build system
GN//die/c/gn.shGoogle’s GN (Chromium ecosystem)
Kconfig//die/c/kconfig.shLinux kernel-style Kconfig
Rust/Cargo//die/rust/cargo.shCargo packages (vendored .pzd)
Go modules//die/go/build.shGo (vendored .pzd)
Meta (hub)//die/hub.shNo build; wires together other packages
Generated//die/gen.shShell-only install step, no compilation

​
Autotools Note

Always use die/c/autorehell.sh instead of die/c/autohell.sh. The autorehell.sh template runs autoreconf to regenerate the build system from configure.ac, which produces cleaner and more reliable results than using a pre-generated configure script. Only fall back to autohell.sh if autoreconf genuinely fails for a particular package. When configure.ac uses AX_* macros from the GNU Autoconf Archive, add bld/auto/archive to bld_tool: 
{% block bld_tool %}
bld/auto/archive
{% endblock %}

​
The Template Inheritance Chain

The templates form a deep inheritance hierarchy. Understanding it helps you know which blocks exist and where to override them. 
base.json                    ← JSON descriptor structure
  └── ix.json                ← standard dep/fetch variable blocks
        └── script.json      ← wraps build script in JSON
              └── sh0.sh     ← build isolation (jail / tmpfs / unshare)
                    └── sh2.sh   ← prepare_f / cleanup_f / fix_mtime / chmod_ro
                          └── sh.sh    ← source_env(), toolchain setup helpers
                                └── base.sh  ← step_* functions + do_* pipeline
                                      └── die/std/ix.sh   ← postinstall, strip, purge_dynlib
                                            └── die/c/ix0.sh  ← wrap_cc plugin injection
                                                  └── die/c/ix1.sh  ← compiler init
                                                        └── die/c/ix2.sh  ← host/target TC setup
                                                              └── die/c/ix3.sh  ← CPPFLAGS / CFLAGS / LDFLAGS
                                                                    └── die/c/ix.sh   ← base C package
                                                                          ├── make.sh
                                                                          │     ├── configure.sh
                                                                          │     │     └── autohell.sh
                                                                          │     │           └── autorehell.sh
                                                                          ├── ninja.sh
                                                                          │     ├── cmake.sh
                                                                          │     └── meson.sh
                                                                          ├── waf.sh
                                                                          ├── gn.sh
                                                                          └── kconfig.sh
Rust and Go share die/c/ix.sh as their base, then diverge: 
die/c/ix.sh
  ├── die/rust/cargo.sh
  └── die/go/base.sh
        └── die/go/build.sh   ← adds vendored module support

​
Rust Packages

Rust packages extend //die/rust/cargo.sh. The template uses vendored dependencies stored as a .pzd archive in the content-addressed store. The build runs cargo build --offline against the vendored tree. 
{% extends '//die/rust/cargo.sh' %}

{% block pkg_name %}
ripgrep
{% endblock %}

{% block version %}
14.1.1
{% endblock %}

{% block cargo_url %}
https://github.com/BurntSushi/ripgrep/archive/refs/tags/{{self.version().strip()}}.tar.gz
{% endblock %}

{% block cargo_sha %}
deadbeef...
{% endblock %}

{% block bld_libs %}
lib/c
{% endblock %}

{% block cargo_features %}
pcre2
{% endblock %}

{% block cargo_bins %}
rg
{% endblock %}
The cargo_sha block holds the SHA-256 of the internally built .pzd vendored archive — not the hash of the downloaded source tarball. See Fetching Sources for the difference. When a Rust package fails to link, check bld_libs first. The Rust linker wrapper (bld/rust/helpers/cc/cc.py) tries three compilers in sequence for each link invocation, so linker errors from missing C libraries appear multiple times in the log — this is normal, not multiple distinct failures.

​
Go Packages

Go packages extend //die/go/build.sh. Like Rust, the build uses a vendored .pzd archive and runs go build -mod=vendor offline. GOOS and GOARCH are set from the target architecture automatically. 
{% extends '//die/go/build.sh' %}

{% block pkg_name %}
git-lfs
{% endblock %}

{% block version %}
3.6.1
{% endblock %}

{% block go_url %}
https://github.com/git-lfs/git-lfs/archive/refs/tags/v{{self.version().strip()}}.tar.gz
{% endblock %}

{% block go_sha %}
2a1f031b45960621119c571c4e82b2418567e7ebdd45514f6dded55e615312b3
{% endblock %}

{% block go_bins %}
git-lfs
{% endblock %}
Key Go-specific blocks:
BlockPurpose
go_urlURL of the source tarball
go_shaSHA-256 of the vendored .pzd archive
go_binsBinaries to copy to ${out}/bin/
go_tagsBuild tags passed as -tags a,b,c
go_toolGo toolchain version (e.g. bin/go/lang/21)
go_refineShell commands to patch sources before vendoring
For repositories with multiple binaries, use the t/ template pattern: a shared base template at bin/foo/t/ix.sh with go_url and go_sha, individual binary packages at bin/foo/bar/ix.sh and bin/foo/baz/ix.sh, and a hub at bin/foo/ix.sh collecting them.

​
Meta Packages (hub)

//die/hub.sh produces no build artifact of its own. It simply declares which other packages form a logical unit. Use it to group packages a user would want together, or to provide a stable name that selects an implementation based on flags or architecture. 
{% extends '//die/hub.sh' %}

{% block run_deps %}
bin/git/cred
bin/git/unwrap
bin/openssh/client
{% endblock %}
Hub packages can also dispatch to versioned implementations: 
{% extends '//die/hub.sh' %}

{% block lib_deps %}
lib/z/{{zlib_ver or ('ng' if x86_64 else 'adler')}}
{% endblock %}
This is the idiomatic way to provide a default implementation that can be overridden with flags: lib/z with default flags on x86_64 resolves to lib/z/ng; lib/z(zlib_ver=stock) resolves to lib/z/stock.
When unsure which template to use, grep the existing package tree for examples:
grep -r 'extends' pkgs/bin/ | grep cmake
grep -r 'extends' pkgs/lib/ | grep meson

Build docs developers (and LLMs) love

Get started for freeTalk to us