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.

IX package dependencies are declared as whitespace-separated lists in Jinja2 blocks. The build infrastructure converts them to JSON arrays automatically and wires up CPPFLAGS, LDFLAGS, and PATH — you never need to hardcode library paths or binary locations. Each block has a specific role: some affect only the current package’s build, others propagate to downstream consumers.

​
Dependency Blocks Overview

BlockRole
bld_libsStatic libraries linked into the artifact (target architecture)
bld_toolExecutables on PATH during the build (host architecture)
std_envFull override of the standard toolchain environment — rarely used
lib_depsLibraries exported to packages that depend on this one
run_depsRuntime packages (binaries, data) needed when this package runs
run_dataRuntime data packages (aux/)
bld_dataBuild-time data packages (aux/, cargo index, go module cache)
host_libsLibraries for the host machine (cross-compilation only)
ind_depsInduced / implicit dependencies

​
bld_libs — Linking Libraries

bld_libs lists every static library the package links against. Each library in this block has its headers and .a files exposed via CPPFLAGS/LDFLAGS automatically through the env_auto.sh mechanism — no manual flag construction needed. 
{% block bld_libs %}
lib/c
lib/c++
lib/z
lib/openssl
lib/curl
lib/expat
{% endblock %}
lib/c is required for virtually every C package. lib/c++ is required for C++ packages. Omitting them produces undefined reference errors at link time. Shim packages (lib/shim/*) also go in bld_libs. See Shims for details.

​
bld_tool — Host Executables

bld_tool lists executables that must be on PATH during the build. These are host-architecture packages from the bld/ tree. 
{% block bld_tool %}
bld/cmake
bld/pkg/config
bld/ninja
bld/perl
{% endblock %}
Common build tools:
PackageProvides
bld/cmakecmake
bld/ninjaninja
bld/pkg/configpkg-config
bld/makemake (usually pulled in automatically by make.sh)
bld/perlperl
bld/pythonpython3
bld/bisonbison + flex
bld/m4m4
bld/gettextmsgfmt, xgettext
bld/waylandwayland-scanner
bld/glibglib-compile-schemas, gdbus-codegen, glib-mkenums
Always use bld/ packages for build-time tools, not bin/ packages. bin/ packages are target binaries and may trigger a full source build for the wrong architecture.

​
lib_deps vs bld_libs

These two blocks solve different problems:
  • bld_libs — libraries needed to build this package. Headers and .a files are available during this package’s build only.
  • lib_deps — libraries that this package re-exports to its consumers. When a downstream package adds lib/mypkg to its bld_libs, it automatically also gets everything in lib/mypkg’s lib_deps.
{% block lib_deps %}
lib/z
lib/openssl
{% endblock %}
Use lib_deps only when downstream consumers genuinely need the same library — typically when this package’s public headers include headers from the dependency, or when its .pc file lists the dependency in Requires.

​
run_deps — Runtime Packages

run_deps lists packages that must be present when this package executes. They are composed into the system realm when this package is installed. 
{% block run_deps %}
bin/openssh/client
bin/git/cred
lib/ncurses
{% endblock %}

​
run_data — Runtime Data

run_data lists data-only packages from aux/ that must be present at runtime. These are non-binary resources such as fonts, terminfo databases, or CA bundles. 
{% block run_data %}
aux/terminfo
aux/ca/bundle
{% endblock %}

​
bld_data — Build-time Data

bld_data lists data packages from aux/ that are needed only during the build — for example, the Cargo crate index or a Go module cache used for offline vendored builds. 
{% block bld_data %}
aux/cargo
{% endblock %}
Go and Rust templates manage this automatically; you rarely need to set bld_data manually.

​
host_libs — Host-Architecture Libraries

host_libs lists libraries that must be compiled for the host machine (the machine running the build) rather than the target. Use this when a package needs to build host-arch tools (code generators, protobuf compilers, etc.) as part of its own build. 
{% block host_libs %}
lib/c
lib/z
{% endblock %}
The Meson template automatically generates a native.ini cross-file when host_libs is non-empty. This keeps host and target compilers fully separated.

​
ind_deps — Induced Dependencies

ind_deps injects implicit dependencies that the build graph would otherwise not detect. Use it for dependencies that are referenced at runtime or load time but are not expressed through lib_deps or run_deps — for example, a plugin loaded via dlopen. 
{% block ind_deps %}
bin/some/plugin
{% endblock %}
This block is uncommon. Prefer run_deps for normal runtime packages.

​
Parameterized Dependencies

Any dependency can be parametrized with flags in parentheses. This selects a specific variant or version of a package: 
{% block bld_libs %}
lib/c
lib/curl(libcurl_ver=http1)
{% endblock %}

{% block run_deps %}
bin/python(python_ver=12)
{% endblock %}
For libraries with version variants (Lua, Python, etc.), use the parameterized /unwrap pattern rather than hardcoding a specific version path: 
bin/foo/unwrap(lua_ver=puc/5/4)
Shims (lib/shim/*) should go in bld_libs, not lib_deps, so they don’t propagate to downstream packages. Only put shims in lib_deps when downstream consumers genuinely need the same workaround. See the Shims page for details.

Build docs developers (and LLMs) love

Get started for freeTalk to us