allyourcodebase

allyourcodebase - организация на GitHub, чьи репозитории решают ровно одну задачу: добавить существующему проекту на C или C++ файл build.zig, чтобы его можно было собирать и кросс-компилировать тулчейном zig. Заявленная цель делится пополам: удобство для пользователей Zig и демонстрация мейнтейнерам upstream'а - готовый рабочий пример того, как выглядит build.zig для их проекта, который можно сразу забрать себе.

Что предлагается взамен

Предложение мейнтейнеру строится на замене зависимостей: добавить зависимость от Zig и убрать несколько других.

Make, CMake, autoconf и гора скриптов на bash, batch и PowerShell вокруг них становятся не нужны, поскольку система сборки Zig берёт на себя их задачи на всех поддерживаемых платформах. Clang уходит, так как полноценный Clang уже встроен в Zig. Системный пакетный менеджер не нужен, потому что Zig умеет сам скачивать и собирать упакованные под него зависимости. Docker и матричные задачи в CI тоже уходят: Zig кросс-компилирует C, C++ и Zig, сводя подготовку релиза к единственному шагу zig build release - организация указывает на superhtml's build.zig как на эталонную реализацию такого шага.

В общем виде утверждение звучит так: Zig избавляет от зависимости от общесистемных настроек, сохраняя возможность подключить их вручную там, где это нужно.

Две стратегии упаковки

Предпочтительный вариант - прописать upstream-проект зависимостью в build.zig.zon, а в репозитории allyourcodebase оставить только build.zig. Исходники upstream'а остаются нетронутыми, а мейнтейнеру для переноса наработок понадобятся ровно два файла.

Запасной вариант - сделать прямой форк upstream-проекта, добавить сборочные скрипты Zig, при желании удалить старую систему сборки и при необходимости пропатчить исходный код. Для самой компиляции патчи обычно не требуются; их реальная польза проявляется там, где нужно подружить шаги сборки с кэшем. В качестве примера приводится специфическая внутренняя утилита сборки (обработчик ассетов или оптимизатор картинок), у которой путь вывода жёстко зашит в текущую рабочую директорию: её переделывают так, чтобы она принимала путь аргументом и кэш Zig мог разместить результат.

Контрибьюторам рекомендуют использовать первую стратегию, а ко второй прибегать только тогда, когда исходники действительно требуют патчей либо когда планируется вычистить все остальные сборочные скрипты и нормально исправить промежуточные шаги.

Перенос в upstream и сопутствующее условие

Мейнтейнеры могут без ограничений забирать всё из этих репозиториев. Если они так поступают, организация просит сообщить об этом через issue, чтобы downstream-репозиторий можно было заархивировать и сослаться на upstream.

При архивации действует одно условие, и это более интересное правило: интеграция в upstream не должна добавлять больше системных зависимостей, чем было в упакованной версии. Если сборка allyourcodebase берёт zstd из allyourcodebase/zstd, upstream-версия должна либо продолжать делать так же, либо использовать механизм опциональных системных библиотек в Zig, оставляя выбор пользователю. Иначе форк остаётся жить и поддерживается параллельно. Смысл в том, чтобы перенесённая в upstream сборка не вернула тайком зависимость от системных пакетов, ради избавления от которой всё и затевалось.

Добавление репозитория

Доступ дают по запросу к kristoff (Loris Cro). Чеклист для нового пакета:

1. Лицензия на собственный build.zig - как минимум не более строгая, чем у upstream-проекта (MIT - всегда безопасный вариант).
2. Упаковывать только C/C++ проект и ничего кроме. Никаких биндингов к Zig: для них нужен отдельный личный репозиторий.
3. Ориентироваться на последний релизный тег Zig.
4. Использовать стратегию с чистым tarball'ом, если патчи или переработка шагов сборки не вынуждают делать форк.
5. CI-задача, подтверждающая успешное выполнение zig build (скрипт для AFLplusplus предлагается как шаблон).
6. Готовность периодически обновлять пакет при выходе новых версий в upstream.

Для поиска репозиторию нужно проставить теги (zig, zig-package).

Постоянные накладные расходы

Правила 3 и 6 - источник постоянной работы, и они завязаны сразу на две движущиеся мишени. Каждый пакет должен отслеживать релизы своего upstream-проекта, и все они обязаны поспевать за релизами Zig, поскольку API системы сборки нестабилен: в returning-to-zig зафиксировано ожидание, что версия 0.17 сломает систему сборки у всех проектов, и каждый подобный релиз потребует массовой правки всех репозиториев организации. Насколько гладко пройдёт эта ревизия, зависит от сохранения интереса у отдельных волонтёров: правило 6 об этом просит, но обеспечить соблюдение ничто не может. Проект находится в watchlist именно по этой причине: идея здравая, а сценарий деградации - тихое устаревание и поломка (bit-rot) в длинном хвосте пакетов, а не явный отказ от проекта.

Имеет смысл сопоставить с zig-incremental-compilation: это вторая половина аргумента в пользу перехода на тулчейн. Система сборки - то, с чем вы взаимодействуете напрямую, а лежащий под ней компилятор даёт выигрыш в скорости итераций.

Организация: https://github.com/allyourcodebase. Лицензия определяется для каждого репозитория индивидуально, при этом общее правило задаёт нижнюю планку: "как минимум не строже, чем в upstream". Количество звёзд точно так же относится к отдельным репозиториям пакетов, а не к организации в целом.