TO DO
Простые пакеты обычно ссылаются на архивы исходных текстов на интернет сайтах. Именно на такие пакеты и была изначально ориентирована система сборки. Такие пакеты подвергаются сначала скачиванию, а потом извлечению исходных текстов из архива. После чего на них, как правило, налагают заплаты (patches).
Поскольку заплаты иногда специфичны для каждой платформы, заплаты налагаются на вязаную копию исходного дерева (см. Вязка исходников) в каталоге платформы. Уже на этой ступени исходные тексты помечаются только для чтения и имеют более одной ссылки на каждый файл.
Затем заплатанное дерево ещё раз вяжется в каталог сборки, уникальный не только по платформе, как заплаты, но и по версиям компонент toolchain и ядра.
И только на этой ступени в каталоге сборки разработчику предлагается вносить свои изменения.
Для внесения изменений в выбранный файл нужно не столько дать себе права записи, сколько отвязать от исходного файла так, чтобы изменения, проверяемые для данной платформы и версий компонентов toolchain, не повлияли на сборку для других платформ и версий toolchain.
Отвязка файла делается скриптом
./xwmake/script/relink-file [-o] file [file ...]
Ключ -o ещё и оставляет файл с расширением ”.orig”.
Пример:
./xwmake/script/relink-file -o var_ПРОЕКТ/bld/last/ПАКЕТ/file.c
Отвязав таким образом файл, его можно отредактировать текстовым редактором.
Затем можно сделать сборку пакета (build) или пересборку (rebuild), если это не в первый раз:
./b rebuild ПАКЕТ
Если при сборке произошла ошибка, последние 20 строк будут выведены на стандартный поток ошибок.
Однако часто этого недостаточно, потому что ошибка находится выше по журналу.
Посмотреть журнал сборки пакета удобно командой
./b build-log ПАКЕТ
при этом для просмотра используется текущий $PAGER. А если переменная среды PAGER не установлена, то журнал просто вываливается на стандартный вывод.
Затем хорошо известный цикл: редактирование -> сборка -> установка -> проверка работы.
После удволетворения итогом, необходимо закрепить изменения.
Поскольку исходные тексты находятся не в нашем ведении, сделать это можно только добавив к пакету заплату - вывод команды diff:
diff -uwpb var_ПРОЕКТ/bld/last/ПАКЕТ/file.c.orig \
var_ПРОЕКТ/bld/last/ПАКЕТ/file.c \
> ПРОЕКТ/pkg/ПАКЕТ/что-исправили.patch
Затем добавить созданный файл заплаты в список заплат пакета, проверить через repatch пакета, что новая заплата подхватывается пакетом на ступени patch и добавить эти изменения (файл заплаты и изменения в файле пакета с добавлением файла заплаты) в свой репозиторий:
git add ПРОЕКТ/pkg/ПАКЕТ/что-исправили.patch
git add ПРОЕКТ/pkg/ПАКЕТ/ПАКЕТ.make
git commit
Некоторые пакеты не имеют в сети интернет доступных архивов исходных текстов, так что их приходится включать в проект непосредственно, а не по ссылке, как простые пакеты.
Это влечёт за собой резкое увеличение размера репозитория и другие недостатки.
Однако есть и достоинство: поскольку мы держим эти исходники у себя в репозитории (часто - в субмодулях git), их можно редактировать непосредственно, фиксируя изменения в наших репозиториях, а не возясь с добавлением заплат на каждое мелкое изменение.
Разумеется, с непосредственно включёнными пакетами можно поступать так же, как и с простыми, но тогда эту секцию можно опустить.
Сборка непосредственных пакетов происходит так же, как и с простыми пакетами, но для укладывания в ступени сборки простых пакетов с целью неусложнения системы сборки, исходные тексты непосредственно включённых пакетов вяжутся ещё дважды: на ступени fetch пакет вяжется из исходного места в каталог загрузки var_ПРОЕКТ/dl/ПАКЕТ и на ступени extract пакет вяжется в каталог для извлечённых архивов var_ПРОЕКТ/src/origin/ПАКЕТ, после чего всё происходит в точности как и с простыми пакетами.
Вследствии всего этого, после вязки такого исходника в каталог сборки число связей большинства файлов достигает 9:
ls -la var_ПРОЕКТ/bld/last/ПАКЕТ/
-r--r--r-- 9 df df 0 Май 15 17:07 .link-count
Способом вносить изменения в эти исходные тексты является цикл:
./b unfetchlog ПАКЕТ
редактируем файл на его исходном месте
./b build ПАКЕТ
Приммечание: цель unfetchlog является комбинацией unfetch и unlog, чтобы журнал предыдущих попыток сборки не мешал смотреть на текущую.
Отредактированный таком образом исходный текст просто фиксируем в репозитори.