Возьмем Audacity.
Haiku: https://github.com/haikuports/haikuports/blob/master/media-sound/audacity/audacity-2.1.2.recipe
Arch: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/audacity
В целом они похожи. Нас будет интересовать фунциональность обоих сборочных систем. Функциональность должна заключаться в гибкости выполнения команд и в автоматизации рутинных операций.
В обоих случаях для сборки выполняются консольные команды.
Но посмотрим на 76 строку рецепта из Haiku https://github.com/haikuports/haikuports/blob/master/media-sound/audacity/audacity-2.1.2.recipe#L76 и 26-ую строку рецепта из Arch https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/audacity#n26
В Haiku команда:
runConfigure ./configure --disable-dynamic-loading --without-lv2 --without-portmixer --disable-nyquist
В Arch команда:
./configure --prefix="/usr" --with-libsndfile="system" <...>
Видим, что сборочная система Haiku способна автоматически подставить разные типовые параметры вызова ./configure, сборщику не нужно вручную задавать префикс и пр. В документации к Arch https://wiki.archlinux.org/index.php/creating_packages#build.28.29 убеждаемся, что это не автоматизируется.
Теперь посмотрим, в какую команду раскрывается макрос %configure в RPM (ALT Linux):
$ rpm --eval '%configure'
CFLAGS="${CFLAGS:--pipe -Wall -g -O2}"; export CFLAGS;
CXXFLAGS="${CXXFLAGS:--pipe -Wall -g -O2}"; export CXXFLAGS;
FFLAGS="${FFLAGS:--pipe -Wall -g -O2}"; export FFLAGS;
[ -n "${ASFLAGS-}" ] || ASFLAGS="$(printf %s '-pipe -Wall -g -O2' |sed -r 's/(^|[[:space:]]+)-[^m][^[:space:]]*//g')"; export ASFLAGS;
export lt_cv_deplibs_check_method=pass_all ;
readlink -e -- './configure' |xargs -ri dirname -- '{}' |xargs -ri find '{}' -type f '(' -name config.sub -or -name config.guess ')' -printf '%h/\n' |sort -u |xargs -rn1 install -pm755 -- /usr/share/gnu-config/config.{sub,guess};
./configure --build=x86_64-alt-linux --host=x86_64-alt-linux \
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib64 \
--libexecdir=/usr/lib \
--localstatedir=/var/lib \
--sharedstatedir=/var/lib \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--disable-dependency-tracking \
Видите, сколько стандартных параметров автоматически подставилось? Это важно, поскольку сборочная система конкретной программы может содержать ошибки и автоматически угадывать их значения, если они вообще не заданы, неверно. В PKGBUILD Arch’a нужно вручную все прописывать. В Haiku runConfigure ./configure автоматически задаст нужные параметры запуска ./configure.
Это был лишь единичный пример, чтобы показать, что PKGBUILD-ы Arch’а нефункциональны в плане отсутствия автоматизации рутинных операций.
В целом, и в Haiku, и в PKGBUILD мало автоматизации.
Например, в обоих случаях вызывается make напрямую (в Haiku это make $jobArgs, а в Арче это make DESTDIR="${pkgdir}" install. В Haiku сборщик пакета должен сам не забыть учесть количество потоков компиляции ($jobArgs), а Arch надеется, что сборочная система конкретного проекта сама прочитает заданную в настройках makepkg переменную окружения, задающую число потоков.
В продвинутых системах сборки, например, RPM, есть макросы, например, %make, который автоматически раскрывается так:
$ rpm --eval '%make_build'
make -j${NPROCS:=4}
Конструкция ${NPROCS:=4} означает, что если значение переменной NPROCS не задано, то принять его равным 4, иначе принять такое, какое задано. При этом 4 — это количество ядер моего процессора, RPM автоматически это посчитало и подобрало число потоков компиляции.
Отправить ответ