Типичный пакет имеет архив исходных текстов, расположенный на публичном сайте интернета, скрипт конфигурации GNU autoconf, Makefile для сборки и установки.
Соответственно, система сборки имеет следующие ступени, обозначенные целями make, связанные в цепочку зависимостей:
fetch -> extract -> patch -> link -> pre-configure -> configure -> build -> install -> pack
Каждая последующая ступень (цель) зависит от предыдущей. Стрелка -> означает направление прохождения ступеней, зависимости же направлены в обратную сторону.
Почти каждая цель имеет свою противоположность - цель с префиксом ‘un’, с обратной цепью зависимостей:
unfetch <- unextract <- unpatch <- unlink <- uninstall <- unpack
Каждая обратная цель отменяет итоги достижения как соответствующей прямой цели, так и всей цепи последующих прямых целей.
Прямая и обратная цепи целей позволяют разработчику пакета отлаживать сборку пакета, двигаясь вперёд и назад по цепи до любой нужной ступени.
Краткое описание целей прямой цепи (сборки):
fetch
Получение архива исходных текстов из интернета или местного хранилища
extract
Извлечение исходных текстов из архива (распаковка)
patch
Наложение заплат
link
Создание копии дерева исходных текстов с заплатами в каталоге сборки пакета
pre-configure
Запуск скриптов типа autoconf из GNU autoconf
configure
Запуск скрипта configure из GNU autoconf
build
Сборка пакета, обычно через “make all”
install
Установка пакета, обычно через “make install”
pack
Упаковка установленных файлов пакета в пакеты opkg. Необзательно
Краткое описание цепи обратных целей:
unfetch
Удаление архива исходных текстов из первого уровня хранения
unextract
Удаление каталога распакованных исходных текстов
unpatch
Удаление каталога исходных текстов с наложенными заплатами
unlink
Удаление каталога сборки пакета
uninstall
Удаление файлов - итогов установки пакета.
unpack
Удаление пакетов opkg.
Поскольку проекты могут быть многоплатформенными, то есть, из одних и тех же исходных текстов собираются образы для разных целевых платформ одновременно (хотя и не параллельно), а многие пакеты не поддерживают раздельную сборку (каталоги сборки и исходных текстов разделены), то необходимо иметь копии исходных текстов в каталогах сборки, разных для разных платформ.
Кроме того, бывают заплаты (patches), вносящие изменения в исходные тексты, подходящие только для одной платформы, а для других платформ необходим другой набор заплат. Таким образом, необходимо иметь копии исходных текстов отдельно для каждого набора заплат.
Применяемое в других системах сборки копирование (разворачивание из архивов) исходных текстов порождает по одной копии исходных текстов на каждую платформу.
При всём этом изменения, как правило, затрагивает небольшую долю исходных файлов, копирование которых оправдано, а вот копирование всех остальных неизменных файлов является избыточным потреблением существенных ресурсов.
Лучшим и простейшим решением проблемы было бы применение техники copy-on-write , однако на широко распространённых сейчас не экзотических файловых системах, она невозможна.
Промежуточным решением является создание связанных файловых деревьев, при котором вместо копирования файла в каталоге-копии создаётся ссылка на файл в исходном каталоге. Copy-on-write при этом осуществляется явным образом, перевязывая подлежащие изменению файлы.
Файловая ссылка (link), часто неправильно называемая hard link, для большого числа файлов является более экономным решением, как по используемому объёму, так и по времени доступа, чем символическая ссылка (symbolic link), часто неправильно называемая “soft link”.
При создании связанных деревьев-“копий” исходных текстов для разных платформ, исходные файлы помечаются атрибутом “только чтение”. Это позволяет избежать непреднамеренного изменения содержимого исходного файла, отображаемого сразу для всех платформ, а также выявить некачественные пакеты, пытающиеся изменить файлы исходных текстов в процессе сборки.
Преднамеренное же изменение файлов-“копий” исходных текстов делается явным образом, отвязывая файл-ссылку от исходного файла и копируя исходный файл в каталог назначения на место удалённого файла-ссылки. Скопированный файл получает атрибут “чтение/запись”, позволяя изменять содержимое, не влияя на отображение исходного файла для других платформ.
Перевязка файла делается утилитой “xwmake/script/relink-file”.
Перевязка файлов для их последующего изменения делается для ступеней сборки пакетов “patch” (автоматически по списку изменяемых заплатами файлов) и, для некоторых пакетов по необходимости, как правило, на ступенях “pre-configue”, “configure”, “build”.
