Основних команд zig build-exe, zig build-lib, zig build-obj і zig test часто достатньо. Однак інколи проект потребує ще одного рівня абстракції, щоб керувати складністю збірки з вихідного коду.
Наприклад, можливо, виникла одна з таких ситуацій:
Командний рядок стає надто довгим і громіздким, і вам потрібно знайти місце, щоб його записати.
Ви хочете створити багато речей, або процес створення складається з багатьох кроків.
Ви хочете скористатися перевагами паралелізму та кешування, щоб скоротити час створення.
Ви хочете відкрити параметри конфігурації для проекту.
Процес збирання відрізняється залежно від цільової системи та інших параметрів.
Ви маєте залежність від інших проектів.
Ви хочете уникнути непотрібної залежності від cmake, make, shell, msvc, python тощо, зробивши проект доступним для більшої кількості учасників.
Ви хочете надати пакет для використання третіми особами.
Ви хочете надати стандартизований спосіб для таких інструментів, як IDE, щоб семантично зрозуміти, як створити проект.
Якщо будь-який із цих варіантів застосовний, проект отримає користь від використання системи Zig Build.
Почнемо
Простий Виконуваний Файл
Цей сценарій збірки створює виконуваний файл із Zig-файлу, який містить загальнодоступне визначення основної функції.
Встановлення Артефактів Збірки
Система збірки Zig, як і більшість систем збірки, базується на моделюванні проекту як спрямованого ациклічного графа (DAG) кроків, які виконуються незалежно та одночасно.
За замовчуванням основним кроком на графіку є крок Встановлення, метою якого є копіювання артефактів збірки в місце їх останнього спочинку. Крок інсталяції починається без залежностей, тому нічого не станеться під час запуску zig build. Сценарій збірки проекту має додати до набору речей для встановлення, що й робить виклик функції installArtifact, наведений вище.
У цьому виводі є два згенерованих каталоги: .zig-cache і zig-out. Перший містить файли, які зроблять наступні збірки швидшими, але ці файли не призначені для перевірки в системі керування джерелами, і цей каталог можна повністю видалити в будь-який час без жодних наслідків.
Другий, zig-out, є "префіксом встановлення". Це відповідає стандартній концепції ієрархії файлової системи. Цей каталог вибирає не проект, а користувач zig build з прапорцем --prefix (скорочено -p).
Ви, як супроводжувач проекту, вибираєте, що буде розміщено в цьому каталозі, але користувач вибирає, де це встановити у своїй системі. Сценарій збірки не може жорстко закодувати вихідні шляхи, оскільки це порушить кешування, паралелізм і компонування, а також дратує кінцевого користувача.
Додавання Зручного Кроку для Запуску Програми
Звичайним є додавання кроку run, щоб надати можливість безпосереднього запуску головної програми з команди побудови.
Основи
Параметри, Надані Користувачем
Використовуйте b.option, щоб зробити сценарій збирання доступним для кінцевих користувачів, а також інших проектів, які залежать від проекту як пакета.
Будь ласка, зверніть вашу увагу на ці рядки:
Project-Specific Options:
-Dwindows=[bool] Target Microsoft Windows
Ця частина меню довідки створюється автоматично на основі запуску логіки build.zig. Таким чином користувачі можуть відкрити параметри конфігурації сценарію збірки.
Стандартні Параметри Конфігурації
Раніше ми використовували прапорець для позначення створення для Windows. Однак ми можемо зробити краще.
Більшість проектів хочуть надати можливість змінювати цільові параметри та налаштування оптимізації. Щоб заохочувати стандартні угоди про іменування цих параметрів, Zig надає допоміжні функції standardTargetOptions і standardOptimizeOption.
Стандартні параметри цілі дозволяють користувачу, який запускає zig build, вибрати, для якої цілі будувати. За замовчуванням дозволено будь-яку ціль, і відсутність вибору означає націлювання на хост-систему. Доступні інші варіанти обмеження підтримуваного цільового набору.
Стандартні параметри оптимізації дозволяють користувачу, який запускає zig build, вибирати між Debug, ReleaseSafe, ReleaseFast і ReleaseSmall. За замовчуванням жоден із варіантів випуску не вважається кращим вибором сценарієм збірки, і користувач повинен прийняти рішення, щоб створити збірку випуску.
Тепер наше меню --help містить більше елементів:
Project-Specific Options:
-Dtarget=[string] The CPU architecture, OS, and ABI to build for
-Dcpu=[string] Target CPU features to add or subtract
-Doptimize=[enum] Prioritize performance, safety, or binary size (-O flag)
Supported Values:
Debug
ReleaseSafe
ReleaseFast
ReleaseSmall
Цілком можливо створити ці параметри безпосередньо за допомогою b.option, але цей API забезпечує загальноприйнятий спосіб іменування цих часто використовуваних параметрів.
Зверніть увагу, що у вихідних даних нашого терміналу ми передали -Dtarget=x86_64-windows -Doptimize=ReleaseSmall. Порівняно з першим прикладом, тепер ми бачимо інші файли в префіксі встановлення:
zig-out/
└── bin
└── hello.exe
Параметри Умовної Компіляції
Щоб передати параметри зі сценарію збірки в Zig-код проекту, скористайтеся кроком Options.
У цьому прикладі дані, надані @import("config"), відомі комп’ютеру, запобігаючи запуску @compileError. Якби ми передали -Dversion=0.2.3 або опустили цей параметр, ми побачили б помилку компіляції app.zig із помилкою "занадто старий".
Статична Бібліотека
Цей сценарій збірки створює статичну бібліотеку з коду Zig, а потім також виконуваний файл з іншого коду Zig, який його споживає.
У цьому випадку буде встановлено лише статичну бібліотеку:
zig-out/
└── lib
└── libfizzbuzz.a
Однак, якщо ви уважно придивитеся, сценарій збірки містить опцію також встановити демонстрацію. Якщо ми додатково передаємо -Denable-demo, то побачимо це в префіксі встановлення:
zig-out/
├── bin
│ └── demo
└── lib
└── libfizzbuzz.a
Зауважте, що незважаючи на безумовний виклик addExecutable, система збирання фактично не витрачає час на створення виконуваного файлу demo, якщо його не запитують за допомогою -Denable-demo, оскільки система збирання базується на Спрямованому Ациклічному Графі з ребрами залежності.
Динамічна бібліотека
Тут ми зберігаємо всі файли такими ж, як у прикладі Static Library, за винятком файлу build.zig.
Як і у прикладі зі статичною бібліотекою, щоб створити для неї посилання на виконуваний файл, використовуйте такий код:
exe.linkLibrary(libfizzbuzz);
Тестування
Окремі файли можна протестувати безпосередньо за допомогою zig test foo.zig, однак складніші випадки використання можна вирішити, організувавши тестування за допомогою сценарію збірки.
Під час використання сценарію побудови модульні тести розбиваються на два різні кроки в графі побудови: крок Компіляція та крок Виконання. Без виклику addRunArtifact, який встановлює межу залежності між цими двома кроками, модульні тести не виконуватимуться.
Етап компіляції можна налаштувати так само, як і будь-який виконуваний файл, бібліотеку чи об’єктний файл, наприклад, шляхом зв’язування із системними бібліотеками, встановлення цільових параметрів або додавання додаткових одиниць компіляції.
Крок «Виконати» можна налаштувати так само, як і будь-який крок «Виконати», наприклад, пропускаючи виконання, коли хост не здатний виконати двійковий файл.
Під час використання системи збірки для запуску модульних тестів, виконавець збірки та засіб виконання тестів спілкуються через stdin і stdout, щоб одночасно запускати кілька пакетів модульних тестів і повідомляти про помилки тестування в змістовний спосіб, не змішуючи їхні результати. Це одна з причин, чому запис у стандартних модульних тестах є проблематичним - це заважатиме цьому каналу зв’язку. З іншого боку, цей механізм увімкне майбутню функцію, яка здатня очікувати паніку від модульного тесту.
У цьому випадку було б корисно ввімкнути skip_foreign_checks для модульних тестів:
Для сценарію використання супроводжуючих проектів на початковому етапі отримання цих бібліотек за допомогою системи Zig Build System забезпечує найменше тертя та ередає повноваження щодо конфігурації в руки тих супроводжуючих. Кожен, хто будує таким чином, матиме придатні для електронного відтворення узгоджені результати, і він працюватиме на кожній операційній системі та навіть підтримуватиме крос-компіляцію. Крім того, це дозволяє проекту з ідеальною точністю визначити точні версії всього дерева залежностей, на основі якого він хоче створити. Очікується, що це буде найкращий спосіб залежати від зовнішніх бібліотек.
Однак для випадку використання пакування програмного забезпечення в репозиторії, такі як Debian, Homebrew або Nix, обов’язковим є зв’язування з системними бібліотеками. Отже, сценарії збірки мають визначати режим і відповідним чином налаштовувати.
Користувачі zig build можуть використовувати --search-prefix для надання додаткових каталогів, які вважаються "системними каталогами" для цілей пошуку статичних і динамічних бібліотек.
Створення Файлів
Запуск Системних Шнструментів
Ця версія hello world очікує знайти файл word.txt у тому самому шляху, і ми хочемо використати системний інструмент, щоб створити його, починаючи з файлу JSON.
Майте на увазі, що системні залежності ускладнять створення вашого проекту для ваших користувачів. Цей сценарій збірки залежить, наприклад, від jq, якого за замовчуванням немає в більшості дистрибутивів Linux і який може бути незнайомим інструментом для користувачів Windows.
У наступному розділі буде замінено jq на інструмент Zig, включений у вихідне дерево, що є кращим підходом.
words.json
{
"en": "world",
"it": "mondo",
"ja": "世界"
}
Вивід
zig-out
├── hello
└── word.txt
Зверніть увагу, як captureStdOut створює тимчасовий файл із результатом виклику jq.
Запуск Інструментів Проекту
Ця версія hello world очікує знайти файл word.txt за тим самим шляхом, і ми хочемо створити його під час збирання, викликавши програму Zig для файлу JSON.
tools/words.json
{
"en": "world",
"it": "mondo",
"ja": "世界"
}
Вивід
zig-out
├── hello
└── word.txt
Створення Файлів для @embedFile
Ця версія hello world хоче @embedFile ресурсу, створеного під час збирання, який ми збираємося створити за допомогою інструменту, написаного мовою Zig.
tools/words.json
{
"en": "world",
"it": "mondo",
"ja": "世界"
}
Вивід
zig-out/
└── bin
└── hello
Створення Вихідного Коду Zig
Цей файл збірки використовує програму Zig для створення файлу Zig, а потім надає його основній програмі як залежність від модуля.
Вивід
zig-out/
└── bin
└── hello
Робота з Одним або Кількома Згенерованими Файлами
Крок WriteFiles забезпечує спосіб створення одного або кількох файлів, які спільно використовують батьківський каталог. Згенерований каталог знаходиться в локальному .zig-cache, і кожен згенерований файл доступний окремо як std.Build.LazyPath. Сам батьківський каталог також доступний як LazyPath.
Цей API підтримує запис довільних рядків у створений каталог, а також копіювання файлів у нього.
Вивід
zig-out/
└── project.tar.gz
Зміна Вихідних Файлів на Місці
Нечасто, але іноді трапляється, що проект передає згенеровані файли в систему керування версіями. Це може бути корисним, коли згенеровані файли рідко оновлюються та мають обтяжливі системні залежності для процесу оновлення, але лише під час процесу оновлення.
Будьте обережні з цією функціональністю; його слід використовувати не під час звичайного процесу збирання, а як утиліту, яку запускає розробник з наміром оновити вихідні файли, які потім будуть передані контролю версій. Якщо це зробити під час звичайного процесу збірки, це спричинить кешування та помилки паралелізму.
Після виконання цієї команди src/protocol.zig оновлюється на місці.
Зручні Приклади
Збірка для Кількох Цілей, щоб Зробити Реліз
У цьому прикладі ми збираємося змінити деякі параметри за замовчуванням під час створення кроку InstallArtifact, щоб розмістити збірку для кожної цілі в окремому підкаталозі всередині шляху встановлення.