Bilingual

Zig Build System Internals
2 days ago
- The Zig build system uses build.zig for configuration and the zig build CLI for execution, compiling a build binary first then executing it as a child process.
- The build binary is built from build_runner.zig in the standard library, which imports the user's build.zig as the @build package.
- The build binary is cached and only recompiled when build.zig or its imports change, avoiding recompilation on subsequent runs.
- The build binary does not embed the Zig compiler; it subprocesses to zig build-exe or other commands to compile artifacts.
- Build steps are defined declaratively in the build function using the Builder API, with dependencies and execution order handled by the build runner.
- Each step has a makeFn function pointer, dependencies, and flags to detect loops and ensure each step executes once.
- The build function supports both void and error union return types, detected via comptime introspection.
- Understanding the internals removes the 'magic' and helps users become more productive with the build system.
The Fedora 45 Sausage Factory
5 days ago
- This document walks through how Fedora turns source code into downloadable artifacts like ISOs, cloud images, container images, and OSTree deployments, using Fedora 45 as the example.
- The process starts with a packager pushing a commit to a package in dist-git (Git repositories at src.fedoraproject.org), where source definitions and downstream patches are stored, while large binaries are kept in a separate lookaside cache.
- Koji, the build system, pulls the Git URL, creates a clean Mock chroot environment for each build, and manages builds through tags, which define build roots and destination tags for packages.
- After building, for branched releases, Bodhi gates updates through a feedback cycle with states like pending, testing, and stable, requiring karma points or testing days before pushing stable updates.
- Pungi composes releases by freezing a package set from a Koji tag, using comps (package groups) and variants XML to define products, then building boot images via Lorax, producing ISOs with xorriso, and creating images with Kiwi and Image Builder.
- Kiwi builds cloud images, Vagrant boxes, container base images, and live ISOs using XML definitions, while Image Builder handles ostree-based and bootc-based artifacts like Atomic Desktop ISOs, Fedora IoT, and Minimal.
- Atomic Desktops like Silverblue use rpm-ostree to compose tree files that produce versioned, checksummed OSTree commits, incorporating packages from comps and treefile specifications.
- Metadata from composes (e.g., composeinfo.json, images.json, rpms.json) is standardized by productmd and used by downstream tools like Anaconda, Bodhi, openQA, and mirror management.
- openQA tests composes automatically by booting images in VMs, running installation and desktop scenarios, and feeding results into release validation.
- Major changes go through a governance process with system-wide or self-contained proposals, reviewed by FESCo, with checkpoints tied to release schedules.
Build Systems Discussion
5 days ago
- The post discusses designing a build system for permacomputing, focusing on the ../lua/civ build system and a proposed package manager.
- A good build system must explicitly define all inputs and outputs for each build phase.
- Make is criticized for being a collection of shell scripts with platform-specific syntax and lacking an overarching structure.
- Another principle is that a build system should allow programmatic configuration of inputs and outputs for different target systems.
- Civ's solution uses a configurable 'sys hub' that abstracts file locations and build logic through a minimal, well-defined API.
- Civ's implementation is lightweight (1000 lines of C utility libraries and ~100 lines of Lua), unlike Bazel which forks Python and is more complex.
- The proposed package manager includes a 'hubrepo' (a git repo) that stores hubs and dependencies, allowing version locking via a .civ.lockfile.
- To submit code to a hub, developers must create a pull request that includes tests and documentation, which is auto-merged by a bot.
Zig – SPIR-V Backend Progress
a month ago
- Package management functionality moved from compiler to build system, improving safety and allowing easier patching.
- SPIR-V backend updated with new @SpirvType builtin, execution mode handling via calling convention, and multi-threaded codegen.
- @bitCast semantics redefined to use logical bit layout, making operations endian-agnostic and more consistent.
- ELF linker improvements support fast incremental compilation and can build the self-hosted Zig compiler with LLVM and LLD.
- Build system reworked to separate configurer and maker processes, speeding up builds and enabling better caching.
- io_uring and Grand Central Dispatch std.Io implementations added for experimental evented I/O.
- Package management enhancements include local zig-pkg directory and --fork flag for easier dependency management.
- Windows standard library prefers native ntdll APIs over kernel32 to avoid overhead and improve reliability.
- zig libc project replaces vendored C code with Zig wrappers, reducing dependency on third-party projects.

build system

Zig Build System Internals

The Fedora 45 Sausage Factory

Build Systems Discussion

Zig – SPIR-V Backend Progress