Система сборки и кросс-компиляция

В мастерской есть маршрутный лист: сначала подготовить детали, затем собрать изделие, затем упаковать. Некоторые операции можно выполнить независимо, другие ждут результат предыдущих. Система сборки хранит такой порядок для программы.

Раньше хватало одного файла и build-exe. Теперь опишем проект с шагами установки, запуска и тестов. Потом выберем другую целевую машину, не притворяясь, что можем запустить её файл на своей.

Одна мысль урока

build.zig описывает зависимости шагов и целевую платформу, а не заменяет код программы.

Опора из прошлого урока: Встроенное тестирование.

От картинки к записи

Система сборки

Zig читает файл build.zig. Его функция build(b: *std.Build) создаёт шаги. Это не точка входа приложения: её выполняет инструмент zig build, чтобы узнать, что и как нужно построить.

Цель

выбирается через standardTargetOptions. Режим оптимизации выбирается через standardOptimizeOption. Эти настройки позволяют передать обычные параметры командной строки вместо переписывания исходника под каждую машину.

В Zig 0.16 сначала создаём модуль через b.createModule. У него указаны корневой файл, target и optimize. Затем b.addExecutable получает .root_module, а не старую форму с .root_source_file напрямую. Пример намеренно использует текущий API целиком: смесь вариантов из разных версий трудно диагностировать.

b.installArtifact(exe) делает программу частью обычного шага установки. После zig build готовый файл окажется в zig-out/bin. Шаг run создаётся отдельно: b.addRunArtifact(exe) знает, какой построенный файл нужно запускать. dependOn связывает пользовательское имя шага с нужным действием.

Тестовый артефакт создаётся b.addTest(.{ .root_module = root }). Само создание артефакта не запускает тесты. Нужен addRunArtifact и зависимость шага test. Это различие важно для проверки: успешная сборка тестового файла ещё не означает, что все его ожидания прошли.

Кросс-компиляция

выбирает другую цель, например aarch64-linux-musl. Компилятор строит код для ARM Linux, даже если хост использует x86_64. Это не добавляет на хост аппаратный ARM и не обещает автоматический запуск. Для выполнения нужен подходящий компьютер или настроенная среда эмуляции.

Не путай целевую платформу с режимом оптимизации. Debug, ReleaseSafe, ReleaseFast и ReleaseSmall отвечают за проверки и оптимизации, а target за свойства получателя. Начинающий использует Debug, чтобы сохранять полезную диагностику. Переключение режима не исправляет неправильный индекс или срок жизни.

В проекте два файла: build.zig и src/main.zig. Команды выполняются из каталога, где лежит build.zig. Один вырванный листинг не проверит согласованность путей. Поэтому ниже дана полная структура, а проверка курса извлекает файлы прямо из этих листингов и собирает проект целиком.