8.4 Системы сборки

В каждом определении пакета указывается система сборки и аргументы для этой системы сборки (see Описание пакетов). Это поле build-system представляет процедуру сборки пакета, а также неявные зависимости этой процедуры сборки.

Системы сборки - это объекты <build-system>. Интерфейс для их создания и управления ими предоставляется модулем (guix build-system), а фактические системы сборки экспортируются определенными модулями.

Под капотом системы сборки сначала компилируют объекты пакета в bag. bag похож на пакет, но с меньшим количеством украшений—другими словами, bag - это представление пакета нижнего уровня, которое включает в себя все входные данные этого пакета, включая те, которые были неявно добавлены система сборки. Это промежуточное представление затем компилируется в derivation (see Деривации). package-with-c-toolchain - это пример способа изменить неявные входные данные, которые использует система сборки пакета (see package-with-c-toolchain).

Системы сборки принимают необязательный список из arguments. В определениях пакетов они передаются через поле arguments (see Описание пакетов). Обычно это аргументы ключевого слова (see keyword arguments in Guile in GNU Guile Reference Manual). Значение этих аргументов обычно оценивается в build stratum—то есть процессом Guile, запущенным демоном (see Деривации).

Основная система сборки - это gnu-build-system, которая реализует стандартную процедуру сборки для GNU и многих других пакетов. Она предоставляется модулем (guix build-system gnu).

Scheme Variable: gnu-build-system

gnu-build-system представляет систему сборки GNU и ее варианты (see configuration and makefile conventions in GNU Coding Standards).

Вкратце, пакеты, использующие его, настраиваются, собираются и устанавливаются с помощью обычной последовательности команд ./configure && make && make check && make install. На практике часто требуется несколько дополнительных шагов. Все эти шаги разделены на отдельные фазы, в частности ¹⁶:

unpack

Распаковать архив исходных текстов и измените текущий каталог на извлеченное дерево исходных текстов. Если источник на самом деле является каталогом, скопировать его в дерево сборки и войдите в этот каталог.

patch-source-shebangs

Изменить shebang, встречающиеся в исходных файлах, чтобы они ссылались на правильные имена файлов хранилища. Например, это изменяет #!/bin/sh на #!/gnu/store/…-bash-4.3/bin/sh.

configure

Запустить сценарий configure с несколькими параметрами по умолчанию, такими как --prefix=/gnu/store/…, а также параметрами, указанными в #:configure-flags аргументе.

build

Запустить make со списком флагов, указанным с помощью #:make-flags. Если аргумент #:parallel-build? истинен (по умолчанию), выполнить сборку с make -j.

check

Запустить make check или другой target, указанный с помощью #:test-target, если только #:tests? #f пройден. Если аргумент #:parallel-tests? истинен (по умолчанию), запустить make check -j.

установка

Запустить make install с флагами, перечисленными в #:make-flags.

patch-shebangs

Изменить shebangs на установленные исполняемые файлы.

strip

Удалить символы отладки из файлов ELF (если #:strip-binaries? не является ложным), скопировав их в выходные данные debug, если они доступны (see Установка файлов отладки).

Модуль на стороне сборки (guix build gnu-build-system) определяет %standard-phase как список фаз сборки по умолчанию. %standard-phase - это список пар символ/процедура, в которых процедура реализует фазу.

See Build Phases, for more info on build phases and ways to customize them.

Кроме того, эта система сборки гарантирует, что доступна “стандартная” среда для пакетов GNU. Сюда входят такие инструменты, как GCC, libc, Coreutils, Bash, Make, Diffutils, grep и sed (полный список см. в модуле (guix build-system gnu)). Мы называем их неявными входами пакета, потому что в определениях пакетов они не упоминаются.

Другие объекты <build-system> определены для поддержки других соглашений и инструментов, используемых пакетами свободного программного обеспечения. Они наследуют большую часть gnu-build-system и различаются в основном набором входных данных, неявно добавляемых в процесс сборки, и списком выполняемых фаз. Некоторые из этих систем сборки перечислены ниже.

Scheme Variable: ant-build-system

Эта переменная экспортируется (guix build-system ant). Она реализует процедуру сборки пакетов Java, которые можно собрать с помощью Ant build tool.

Она добавляет к набору входных данных как ant, так и Java Development Kit (JDK), предоставленные пакетом icedtea. Различные пакеты можно указать с помощью параметров #:ant и #:jdk соответственно.

Когда исходный пакет не предоставляет подходящий файл сборки Ant, параметр #:jar-name можно использовать для создания минимального файла сборки Ant build.xml с задачами для создания указанного архива jar. В этом случае параметр #:source-dir можно использовать для указания подкаталога источника, по умолчанию - src.

Параметр #:main-class можно использовать с минимальным файлом сборки ant для указания основного класса результирующего jar-файла. Это делает файл jar исполняемым. Параметр #:test-include можно использовать для указания списка запускаемых тестов junit. По умолчанию это (list "**/*Test.java"). #:test-exclude можно использовать для отключения некоторых тестов. По умолчанию это (list "**/Abstract*.java"), потому что абстрактные классы не могут быть запущены как тесты.

Параметр #:build-target можно использовать для указания задачи Ant, которая должна выполняться на этапе build. По умолчанию будет запущена задача jar.

Scheme Variable: android-ndk-build-system

Эта переменная экспортируется (guix build-system android-ndk). Она реализует процедуру сборки пакетов Android NDK (собственный комплект разработки) с использованием процесса сборки, специфичного для Guix.

Система сборки предполагает, что пакеты устанавливают свои файлы общедоступного интерфейса (заголовки) в подкаталог include вывода out, а их библиотеки - в подкаталог lib вывода out.

Также предполагается, что объединение всех зависимостей пакета не имеет конфликтующих файлов.

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

Scheme Variable: asdf-build-system/source

Scheme Variable: asdf-build-system/sbcl

Scheme Variable: asdf-build-system/ecl

Эти переменные, экспортированные (guix build-system asdf), реализуют процедуры сборки для пакетов Common Lisp с использованием “ASDF”. ASDF - это средство определения системы для программ и библиотек Common Lisp.

Система asdf-build-system/source устанавливает пакеты в исходной форме и может быть загружена с использованием любой распространенной реализации Lisp через ASDF. Другие, такие как asdf-build-system/sbcl, устанавливают двоичные системы в формате, понятном конкретной реализации. Эти системы сборки также могут использоваться для создания исполняемых программ или образов lisp, которые содержат набор предварительно загруженных пакетов.

В системе сборки используются соглашения об именах. Для бинарных пакетов перед именем пакета должен стоять префикс реализации lisp, например sbcl- для asdf-build-system/sbcl.

Кроме того, соответствующий исходный пакет должен быть помечен с использованием того же соглашения, что и пакеты python (см. Модули Python), с использованием префикса cl-.

Для binary пакетов каждая система должна быть определена как пакет Guix. Если один пакет origin содержит несколько систем, можно создать варианты пакета, чтобы собрать все системы. Пакеты с исходным кодом, в которых используется asdf-build-system/source, могут содержать несколько систем.

Для создания исполняемых программ и образов можно использовать процедуры сборки build-program и build-image. Их следует вызывать в фазе сборки после фазы create-symlinks, чтобы только что созданную систему можно было использовать в полученном образе. build-program требует, чтобы список выражений Common Lisp был передан в качестве аргумента #:entry-program.

Если система не определена в собственном файле .asd с тем же именем, тогда следует использовать параметр #:asd-file, чтобы указать, в каком файле определена система. Кроме того, если пакет определяет систему для своих тестов в отдельном файле, он будет загружен перед запуском тестов, если он указан параметром #:test-asd-file. Если он не установлен, будут попробованы файлы <system>-tests.asd, <system>-test.asd, tests.asd и test.asd, если они есть.

Если по какой-то причине пакет должен быть назван иначе, чем это предлагается в соглашениях об именах, можно использовать параметр #:asd-system-name для указания имени системы.

Scheme Variable: cargo-build-system

Эта переменная экспортируется (guix build-system cargo). Она поддерживает сборку пакетов с использованием Cargo, инструмента сборки языка программирования Rust.

Она добавляет rustc и cargo к набору входных данных. Другой пакет Rust можно указать с помощью параметра #:rust.

Обычные cargo зависимости должны быть добавлены к определению пакета через параметр #:cargo-inputs в виде списка пар имени и спецификации, где спецификацией может быть определение пакета или источника. Обратите внимание, что в спецификации должен быть указан путь к сжатому архиву, который содержит файл Cargo.toml в своем корне, иначе он будет проигнорирован. Точно так же dev-зависимости cargo должны быть добавлены в определение пакета с помощью параметра #:cargo-development-inputs.

На этапе configure эта система сборки собирет любые исходные данные, указанные в параметрах #:cargo-inputs и #:cargo-development-inputs, доступными для cargo. Она также удалит файл Cargo.lock, который будет воссоздан cargo на этапе build. На этапе install устанавливаются двоичные файлы, определенные crate.

Scheme Variable: copy-build-system

Эта переменная экспортируется в (guix build-system copy). Она поддерживает сборку простых пакетов, которые не требуют большой компиляции, в основном просто перемещения файлов.

Она добавляет большую часть пакетов gnu-build-system в набор входных данных. По этой причине copy-build-system не требуется весь шаблонный код, часто необходимый для trivial-build-system.

Чтобы еще больше упростить процесс установки файла, предоставляется аргумент #:install-plan, позволяющий упаковщику указывать, какие файлы куда установить. План установки представляет собой список (source target [filters]). filters необязательны.

• Когда source соответствует файл или каталог без косой черты, установить его в target.
  • Если target имеет косую черту в конце, установить source basename ниже target.
  • Otherwise install source as target.
• Когда source - это каталог с косой чертой в конце или когда используются filters, завершающая косая черта target подразумевается с тем же значением, что и выше.
  • Без filter установить содержимое source в target.
  • С filters среди #:include, #:include-regexp, #:exclude, #:exclude-regexp, установить только избранные файлы в зависимости от фильтров. Каждый фильтр определяется списком строк.
    • С помощью #:include установите все файлы, суффикс пути которых соответствует хотя бы одному из элементов в данном списке.
    • С помощью #:include-regex установить все файлы, подкаталоги которых соответствуют хотя бы одному из регулярных выражений в данном списке.
    • Фильтры #:exclude и #:exclude-regexp являются дополнением к своим аналогам включения. Без флагов #:include установить все файлы, кроме тех, которые соответствуют фильтрам исключения. Если указаны и включения, и исключения, исключения выполняются поверх включений.

  В любом случае пути, относительные к source, сохраняются в target.

Примеры:

• ("foo/bar" "share/my-app/"): Установить bar в share/my-app/bar."
• ("foo/bar" "share/my-app/baz"): Установить bar в share/my-app/baz.
• ("foo/" "share/my-app"): Установить содержимое foo в share/my-app, например, установить foo/sub/file в share/my-app/sub/file.
• ("foo/" "share/my-app" #:include ("sub/file")): Установить только foo/sub/file в share/my-app/sub/file.
• ("foo/sub" "share/my-app" #:include ("file")): Установить foo/sub/file в share/my-app/file.

Scheme Variable: clojure-build-system

Эта переменная экспортируется (guix build-system clojure). Она реализует простую процедуру сборки пакетов Clojure с использованием простого старого compile в Clojure. Кросс-компиляция пока не поддерживается.

Она добавляет clojure, icedtea и zip к набору входных данных. Различные пакеты можно указать с помощью параметров #:clojure, #:jdk и #:zip соответственно.

Список исходных каталогов, тестовых каталогов и имен jar-файлов можно указать с помощью параметров #:source-dirs, #:test-dirs и #:jar-names соответственно. Каталог компиляции и основной класс можно указать с помощью параметров #:compile-dir и #:main-class соответственно. Остальные параметры описаны ниже.

Эта система сборки является расширением ant-build-system, но со следующими изменениями:

build

На этом этапе вызывается compile в Clojure для компиляции исходных файлов и запускается jar для создания jar-файлов как из исходных файлов, так и из скомпилированных файлов в соответствии со списком включения и списком исключений, указанным в #:aot-include и #:aot-exclude соответственно. Список исключений имеет приоритет над списком включения. Эти списки состоят из символов, представляющих библиотеки Clojure, или специального ключевого слова #:all, представляющего все библиотеки Clojure, находящиеся в исходных каталогах. Параметр #:omit-source? определяет, следует ли включать исходники в jar-файлы.

check

На этом этапе выполняются тесты в соответствии со списком включения и списком исключений, указанными в #:test-include и #:test-exclude соответственно. Их значения аналогичны значениям #:aot-include и #:aot-exclude, за исключением того, что специальное ключевое слово #:all теперь обозначает все библиотеки Clojure, находящиеся в каталогах test. Параметр #:tests? определяет, нужно ли запускать тесты.

установка

На этом этапе устанавливаются все созданные ранее jars.

Помимо вышесказанного, эта система сборки также содержит дополнительную фазу:

install-doc

На этом этапе устанавливаются все файлы верхнего уровня с базовым именем, совпадающим с %doc-regex. Другое регулярное выражение можно указать с помощью параметра #:doc-regex. Все файлы (рекурсивно) в каталогах документации, указанные в #:doc-dirs, также устанавливаются.

Scheme переменная: cmake-build-system

Эта переменная экспортируется (guix build-system cmake). Она реализует процедуру сборки пакетов с использованием инструмента сборки CMake.

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

Параметр #:configure-flags используется как список флагов, переданных команде cmake. Параметр #:build-type абстрактно определяет флаги, передаваемые компилятору; по умолчанию используется "RelWithDebInfo" (сокращение от “release mode с отладочной информацией”), что примерно означает, что код компилируется с помощью -O2 -g, как в случае пакетов на основе Autoconf по умолчанию.

Scheme переменная: dune-build-system

Эта переменная экспортируется в (guix build-system dune). Она поддерживает сборку пакетов с использованием Dune, инструмента сборки для языка программирования OCaml. Она реализована как расширение ocaml-build-system, описанную ниже. Таким образом, в эту систему сборки можно передать параметры #:ocaml и #:findlib.

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

Фаза configure отсутствует, потому что dune пакеты обычно не нужно настраивать. Параметр #:build-flags используется как список флагов, переданных команде dune во время сборки.

Параметр #:jbuild? можно передать для использования команды jbuild вместо более новой команды dune при сборке пакета. Его значение по умолчанию - #f.

Параметр #:package может быть передан для указания имени пакета, что полезно, когда пакет содержит несколько пакетов, и вы хотите создать только один из них. Это эквивалентно передаче аргумента -p в dune.

Scheme переменная: go-build-system

Эта переменная экспортируется (guix build-system go). Онf реализует процедуру сборки пакетов Go с использованием стандартного механизмов сборки Go.

Ожидается, что пользователь предоставит значение для ключа #:import-path и, в некоторых случаях, #:unpack-path. import path соответствует пути к файловой системе, ожидаемому сценариями сборки пакета и любыми ссылочными пакетами, и обеспечивает уникальный способ ссылки на Go пакет. Обычно он основан на комбинации удаленного URI исходного кода пакета и иерархической структуры файловой системы. В некоторых случаях вам нужно будет распаковать исходный код пакета в другую структуру каталогов, отличную от той, которая указана в пути импорта, и в таких случаях следует использовать #:unpack-path.

Пакеты, которые предоставляют библиотеки Go, должны устанавливать свой исходный код во встроенные выходные данные. Ключ #:install-source?, который по умолчанию равен #t, определяет, установливается ли исходный код. Для пакетов, которые предоставляют только исполняемые файлы, может быть установлено значение #f.

Scheme переменная: glib-or-gtk-build-system

Эта переменная экспортируется в (guix build-system glib-or-gtk). Она предназначена для использования с пакетами, использующими GLib или GTK+.

Эта система сборки добавляет следующие две фазы к тем, которые определены в gnu-build-system:

glib-or-gtk-wrap

Фаза glib-or-gtk-wrap гарантирует, что программы в bin/ смогут найти GLib “schemas” и модули GTK+. Это достигается путем включения программ в сценарии запуска, которые соответствующим образом устанавливают переменные среды XDG_DATA_DIRS и GTK_PATH.

Можно исключить определенные выходные данные пакета из этого процесса упаковки, указав их имена в параметре #:glib-or-gtk-wrap-excluded-output. Это полезно, когда известно, что выходной файл не содержит двоичных файлов GLib или GTK+, и где wrapping может произвольно добавить зависимость этого вывода от GLib и GTK+.

glib-or-gtk-compile-schemas

Фаза glib-or-gtk-compile-schemas гарантирует, что все GSettings schemas в GLib скомпилированы. Компиляция выполняется программой glib-compile-schemas. Она предоставляется пакетом glib:bin, который автоматически импортируется системой сборки. Пакет glib, предоставляющий glib-compile-schemas, можно указать с помощью параметра #:glib.

Обе фазы выполняются после фазы install.

Scheme переменная: guile-build-system

Эта система сборки предназначена для пакетов Guile, которые состоят исключительно из кода Scheme и настолько скудны, что у них даже нет make-файла, не говоря уже о сценарии configure. Она компилирует Scheme код с помощью guild compile (see Compilation in GNU Guile Reference Manual) и устанавливает файлы .scm и .go в нужное место. Она также устанавливает документацию.

Эта система сборки поддерживает кросс-компиляцию с использованием параметра --target в ‘guild compile’.

Пакеты, созданные с помощью guile-build-system, должны содержать пакет Guile в поле native-inputs.

Scheme переменная: julia-build-system

Эта переменная экспортируется в (guix build-system julia). Она реализует процедуру сборки, используемую пакетами julia, которая по сути аналогична запуску ‘julia -e 'используя Pkg; Pkg.add(package)'’ в среде, где JULIA_LOAD_PATH содержит пути ко всем входным данным пакета Julia. Тесты запускаются с Pkg.test.

Пакеты Julia требуют, чтобы исходный код file-name был настоящим именем пакета, написанным с заглавной буквы.

Для пакетов, требующих зависимостей shared библиотек, вам может потребоваться вручную написать файл /deps/deps.jl. Обычно это строка const variable = /gnu/store/library.so для каждой зависимости плюс void функция check_deps() = nothing.

Некоторые старые пакеты, которые еще не используют Package.toml, также потребуют создания этого файла. Функция julia-create-package-toml помогает создать файл. Вам необходимо передать выходные данные и источник пакета, его имя (такое же, как параметр file-name), uuid пакета, версию пакета и список зависимостей, указанных по их имени и их uuid.

Scheme Variable: maven-build-system

Эта переменная экспортируется в (guix build-system maven). Она реализует процедуру сборки пакетов Maven. Maven - это инструмент для управления зависимостями и жизненным циклом Java. Пользователь Maven указывает зависимости и плагины в файле pom.xml, который читает Maven. Когда Maven не имеет одной из зависимостей или плагинов в своем репозитории, он загружает их и использует для сборки пакета.

Система сборки maven гарантирует, что maven не будет пытаться загрузить какие-либо зависимости, работая в offline режиме. Maven завершится ошибкой, если зависимость отсутствует. Перед запуском Maven pom.xml (и подпроекты) модифицируются, чтобы указать версию зависимостей и плагинов, которые соответствуют версиям, доступным в среде сборки guix. Зависимости и плагины должны быть установлены в поддельном репозитории maven по адресу lib/m2 и перед запуском maven привязаны к соответствующему репозиторию. Maven получает указание использовать этот репозиторий для сборки и устанавливает туда созданные артефакты. Измененные файлы копируются в каталог lib/m2 выходных данных пакета.

Вы можете указать файл pom.xml с аргументом #:pom-file или позволить системе сборки использовать файл pom.xml по умолчанию в источниках.

Если вам нужно указать версию зависимости вручную, вы можете использовать аргумент #:local-packages. Он принимает список ассоциаций, где ключ - это groupId пакета, а его значение - это список ассоциаций, где ключ - это artifactId пакета, а его значение - это версия, которую вы хотите переопределить в pom.xml.

Некоторые пакеты используют зависимости или плагины, которые не используются ни во время выполнения, ни во время сборки в Guix. Вы можете изменить файл pom.xml, чтобы удалить их, используя аргумент #:exclude. Его значение - это список ассоциаций, где ключ - это groupId плагина или зависимости, которые вы хотите удалить, а значение - это список artifactId, которые вы хотите удалить.

Вы можете переопределить пакеты по умолчанию jdk и maven с помощью соответствующего аргумента, #:jdk и #:maven.

Аргумент #:maven-plugins - это список подключаемых модулей maven, используемых во время сборки, в том же формате, что и поля inputs в объявлении пакета. Его значение по умолчанию - (default-maven-plugins), которое также экспортируется.

Scheme переменная: minify-build-system

Эта переменная экспортируется в (guix build-system minify). Она реализует процедуру минификации для простых пакетов JavaScript.

Он добавляет uglify-js к набору входных данных и использует его для сжатия всех файлов JavaScript в каталоге src. Другой minifier пакет можно указать с помощью параметра #:uglify-js, но ожидается, что этот пакет запишет минимизированный код в стандартный вывод.

Когда не все входные файлы JavaScript находятся в каталоге src, можно использовать параметр #:javascript-files, чтобы указать список имен файлов для передачи в minifier.

Scheme переменная: ocaml-build-system

Эта переменная экспортируется в (guix build-system ocaml). Она реализует процедуру сборки пакетов OCaml, которая заключается в выборе правильного набора команд для запуска для каждого пакета. Пакеты OCaml могут ожидать выполнения множества различных команд. Эта система сборки попробует некоторые из них.

Если в пакете есть файл setup.ml на верхнем уровне, он будет запускать ocaml setup.ml -configure, ocaml setup.ml -build и ocaml setup.ml -install. Система сборки предполагает, что этот файл был сгенерирован OASIS, и позаботится об установке префикса и включении тестов, если они не отключены. Вы можете передать флаги конфигурации и сборки с помощью #:configure-flags и #:build-flags. Ключ #:test-flags может быть передан для изменения набора флагов, используемых для включения тестов. Ключ #:use-make? можно использовать для обхода этой системы на этапах сборки и установки.

Когда в пакете есть файл configure, предполагается, что это созданный вручную скрипт настройки, для которого требуется другой формат аргументов, чем в gnu-build-system. Вы можете добавить дополнительные флаги с помощью клавиши #:configure-flags.

Когда в пакете есть файл Makefile (или #:use-make? - это #t), он будет использоваться, и дополнительные флаги могут быть переданы на этапы сборки и установки с #:make-flags ключом.

Наконец, некоторые пакеты не имеют этих файлов и используют стандартное расположение для своей системы сборки. В этом случае система сборки запустит ocaml pkg/pkg.ml или ocaml pkg/build.ml и позаботится о предоставлении пути к необходимому модулю findlib. Дополнительные флаги можно передать с помощью ключа #:build-flags. Об установке позаботится opam-installer. В этом случае пакет opam необходимо добавить в поле native-inputs в определении пакета.

Обратите внимание, что большинство пакетов OCaml предполагают, что они будут установлены в том же каталоге, что и OCaml, что не является тем, что мы хотим в guix. В частности, они устанавливают файлы .so в каталог своего модуля, что обычно нормально, потому что он находится в каталоге компилятора OCaml. Однако в guix эти библиотеки нельзя найти, и мы используем CAML_LD_LIBRARY_PATH. Эта переменная указывает на lib/ocaml/site-lib/stubslibs, и именно здесь должны быть установлены библиотеки .so.

Scheme переменная: python-build-system

Эта переменная экспортируется в (guix build-system python). Она реализует более или менее стандартную процедуру сборки, используемую пакетами Python, которая заключается в запуске python setup.py build, а затем python setup.py install --prefix=/gnu/store/….

Для пакетов, которые устанавливают само-достаточные программы Python в bin/, она заботится об обертке этих программ, чтобы их переменная среды PYTHONPATH указывала на все библиотеки Python, от которых они зависят.

Какой пакет Python используется для сборки, можно указать с помощью параметра #:python. Это полезный способ принудительно создать пакет для определенной версии интерпретатора Python, что может потребоваться, если пакет совместим только с одной версией интерпретатора.

По умолчанию guix вызывает setup.py под управлением setuptools, как и pip. Некоторые пакеты несовместимы с setuptools (и pip), поэтому вы можете отключить это, установив для параметра #:use-setuptools? значение #f.

Scheme Variable: perl-build-system

Эта переменная экспортируется в (guix build-system perl). Она реализует стандартную процедуру сборки для пакетов Perl, которая заключается либо в запуске perl Build.PL --prefix=/gnu/store/…, за которым следуют Build и Build install; или при запуске perl Makefile.PL PREFIX=/gnu/store/…, за которым следуют make и make install, в зависимости от того, какой из Build.PL или Makefile.PL присутствует в дистрибутиве пакета. Предпочтение отдается первому, если в дистрибутиве пакета есть и Build.PL, и Makefile.PL. Это предпочтение можно отменить, указав #t для параметра #:make-maker?.

Первоначальный вызов perl Makefile.PL или perl Build.PL передает флаги, указанные в параметре #:make-maker-flags или #:module-build-flags, соответственно.

Какой пакет Perl используется, можно указать с помощью #:perl.

Scheme переменная: qt-build-system

Эта переменная экспортируется в (guix build-system qt). Она предназначена для использования с приложениями, использующими Qt или KDE.

Эта система сборки добавляет следующие две фазы к тем, которые определены в cmake-build-system:

check-setup

Фаза check-setup подготавливает среду к запуску проверок, которые обычно используются тестовыми программами Qt. Пока это устанавливает только некоторые переменные среды: QT_QPA_PLATFORM=offscreen, DBUS_FATAL_WARNINGS=0 и CTEST_OUTPUT_ON_FAILURE=1.

Этот этап добавляется перед этапом check. Это отдельный этап для облегчения настройки.

qt-wrap

Фаза qt-wrap ищет пути к плагинам Qt5, пути QML и некоторый XDG во входных и выходных данных. Если путь найден, все программы в выходных каталогах bin/, sbin/, libexec/ и lib/libexec/ заключены в сценарии, определяющие необходимые environment переменные.

Можно исключить определенные выходные данные пакета из этого процесса упаковки, указав их имена в параметре #:qt-wrap-excluded-output. Это полезно, когда известно, что вывод не содержит никаких двоичных файлов Qt, и когда обертка может произвольно добавить зависимость этого вывода от Qt, KDE и т.п.

Эта фаза добавляется после фазы install.

Scheme Variable: r-build-system

Эта переменная экспортируется в (guix build-system r). Она реализует процедуру сборки, используемую пакетами R, которая, по сути, немного больше, чем запуск ‘R CMD INSTALL --library=/gnu/store/…’ в среде, где R_LIBS_SITE содержит пути ко всем входам пакета R. Тесты запускаются после установки с использованием R-функции tools::testInstalledPackage.

Scheme переменная: rakudo-build-system

Эта переменная экспортируется (guix build-system rakudo). Она реализует процедуру сборки, используемую Rakudo для пакетов Perl6. Она устанавливает пакет в /gnu/store/…/NAME-VERSION/share/perl6 и устанавливает двоичные файлы, файлы библиотеки и resources, а также помещает файлы в bin/ каталог. Тесты можно пропустить, передав #f параметру tests?.

Какой пакет rakudo используется, можно указать с помощью rakudo. Какой пакет perl6-tap-harness, используемый для тестов, можно указать с помощью #:verify6 или удалить, передав #f в параметр with-verify6?. Какой пакет perl6-zef, используемый для тестирования и установки, можно указать с помощью #:zef или удалить, передав #f в параметр with-zef?.

Scheme переменная: texlive-build-system

Эта переменная экспортируется в (guix build-system texlive). Она используется для сборки пакетов TeX в batch режиме с указанным движком. Система сборки устанавливает переменную TEXINPUTS для поиска всех исходных файлов TeX во входных данных.

По умолчанию она запускает luatex для всех файлов, заканчивающихся на ins. Другой механизм и формат можно указать с помощью аргумента #:tex-format. Различные цели сборки могут быть указаны с помощью аргумента #:build-target, который ожидает список имен файлов. Система сборки добавляет к входам только texlive-bin и texlive-latex-base (оба из (gnu packages tex). Оба могут быть переопределены с помощью аргументов #:texlive-bin и #:texlive-latex-base соответственно.

Параметр #:tex-directory сообщает системе сборки, где установить созданные файлы в дереве texmf."

Scheme переменная: ruby-build-system

Эта переменная экспортируется в (guix build-system ruby). Она реализует процедуру сборки RubyGems, используемую пакетами Ruby, которая включает запуск gem build, за которым следует gem install.

Поле source пакета, использующего эту систему сборки, обычно ссылается на gem архив, поскольку это формат, который разработчики Ruby используют при выпуске своего программного обеспечения. Система сборки распаковывает gem архив, потенциально исправляет исходный код, запускает набор тестов, переупаковывает gem и устанавливает его. Кроме того, на каталоги и архивы можно ссылаться, чтобы можно было создавать unreleased gem’ы из Git или традиционного архива с исходным кодом.

Какой пакет Ruby используется, можно указать с помощью параметра #:ruby. Список дополнительных флагов, передаваемых команде gem, можно указать с помощью параметра #:gem-flags.

Scheme переменная: waf-build-system

Эта переменная экспортируется в (guix build-system waf). Она реализует процедуру сборки вокруг сценария waf. Общие этапы—configure, build и install—реализуются путем передачи их имен в качестве аргументов сценарию waf.

Скрипт waf выполняется интерпретатором Python. Какой пакет Python используется для запуска сценария, можно указать с помощью параметра #:python.

Scheme переменная: scons-build-system

Эта переменная экспортируется в (guix build-system scons). Она реализует процедуру сборки, используемую инструментом сборки программного обеспечения SCons. Эта система сборки запускает scons для сборки пакета, scons test для запуска тестов и затем scons install для установки пакета.

Дополнительные флаги, передаваемые в scons, можно указать с помощью параметра #:scons-flags. Цели сборки и установки по умолчанию могут быть переопределены с помощью #:build-target и #:install-target соответственно. Версия Python, используемая для запуска SCons, может быть указана путем выбора соответствующего пакета SCons с параметром #:scons.

Scheme переменная: haskell-build-system

Эта переменная экспортируется в (guix build-system haskell). Она реализует процедуру сборки Cabal, используемую пакетами Haskell, которая включает запуск runhaskell Setup.hs configure --prefix=/gnu/store/… и runhaskell Setup.hs build. Вместо установки пакета путем запуска runhaskell Setup.hs install, чтобы избежать попыток регистрации библиотек в каталоге хранилища компилятора только для чтения, система сборки использует runhaskell Setup.hs copy, за которым следует runhaskell Setup.hs register. Кроме того, система сборки генерирует документацию по пакету, запуская runhaskell Setup.hs haddock, если только #:haddock? #f пройден. Дополнительные параметры можно передать с помощью параметра #:haddock-flags. Если файл Setup.hs не найден, система сборки вместо этого ищет Setup.lhs.

Какой компилятор Haskell используется, можно указать с помощью параметра #:haskell, который по умолчанию равен ghc.

Scheme переменная: dub-build-system

Эта переменная экспортируется в (guix build-system dub). Она реализует процедуру сборки Dub, используемую пакетами D, которая включает запуск dub build и dub run. Установка осуществляется путем копирования файлов вручную.

Какой компилятор D используется, можно указать с помощью параметра #:ldc, который по умолчанию равен ldc.

Scheme переменная: emacs-build-system

Эта переменная экспортируется в (guix build-system emacs). Она реализует процедуру установки, аналогичную системе упаковки самого Emacs (see Packages in The GNU Emacs Manual).

Сначала она создает файл package-autoloads.el, а затем байт-компилирует все файлы Emacs Lisp. В отличие от системы упаковки Emacs, файлы документации Info перемещаются в стандартный каталог документации, а файл dir удаляется. Файлы пакета Elisp устанавливаются непосредственно в share/emacs/site-lisp.

Scheme переменная: font-build-system

Эта переменная экспортируется в (guix build-system font). Она реализует процедуру установки для пакетов шрифтов, в которой upstream предоставляет предварительно скомпилированные файлы TrueType, OpenType и т.д. файлы шрифтов, которые необходимо просто скопировать на место. Она копирует файлы шрифтов в стандартные места выходного каталога.

Scheme переменная: meson-build-system

Эта переменная экспортируется в (guix build-system meson). Она реализует процедуру сборки для пакетов, которые используют Meson в качестве своей системы сборки.

Она добавляет к набору входов как Meson, так и Ninja, и их можно изменить с помощью параметров #:meson и #:ninja. если нужно. По умолчанию Meson - это meson-for-build, что является особенным, потому что он не очищает RUNPATH от двоичных файлов и библиотек при их установке.

Эта система сборки является расширением gnu-build-system, но со следующими фазами, измененными на некоторые специфичные для Meson:

configure

На этапе выполняется meson с флагами, указанными в #:configure-flags. Флаг --buildtype всегда установлен на debugoptimized, если что-то еще не указано в #:build-type.

build

На этапе выполняется ninja для параллельной сборки пакета по умолчанию, но это можно изменить с помощью #:parallel-build?.

check

На этапе выполняется ninja с целью, указанной в #:test-target, по умолчанию это "test".

установка

Фаза выполняется ninja install и не может быть изменен.

Помимо этого, система сборки также добавляет следующие фазы:

fix-runpath

Эта фаза гарантирует, что все двоичные файлы могут найти нужные библиотеки. Она ищет необходимые библиотеки в подкаталогах собираемого пакета и, при необходимости, добавляет их в RUNPATH. Она также удаляет ссылки на библиотеки, оставшиеся от фазы сборки meson-for-build, такие как тестовые зависимости, которые на самом деле не требуются для запуска программы.

glib-or-gtk-wrap

Эта фаза предоставляется glib-or-gtk-build-system и по умолчанию не включена. Ее можно включить с помощью #:glib-or-gtk?.

glib-or-gtk-compile-schemas

Эта фаза предоставляется glib-or-gtk-build-system и по умолчанию не включена. Ее можно включить с помощью #:glib-or-gtk?.

Scheme переменная: linux-module-build-system

linux-module-build-system позволяет создавать модули ядра Linux.

Эта система сборки является расширением gnu-build-system, но со следующими изменениями:

configure

На этой фазе среда настраивается таким образом, чтобы Makefile ядра Linux можно было использовать для сборки внешнего модуля ядра.

build

На этой фазе используется Makefile ядра Linux для сборки внешнего модуля ядра.

установка

На этой фазе используется Makefile ядра Linux для установки внешнего модуля ядра.

Возможно и полезно указать ядро Linux, которое будет использоваться для сборки модуля (в форме arguments пакета с использованием linux-module-build-system используйте ключ #:linux, чтобы указать это).

Scheme переменная: node-build-system

Эта переменная экспортируется в (guix build-system node). Она реализует процедуру сборки, используемую Node.js, которая реализует аппроксимацию команды npm install, за которой следует команда npm test.

Какой пакет Node.js используется для интерпретации команд npm, можно указать с помощью параметра #:node, который по умолчанию равен node.

Наконец, для пакетов, которым не нужно ничего столь же сложного, предоставляется “trivial” система сборки. Она тривиальна в том смысле, что она практически не оказывает поддержки при сборке: она не извлекает никаких неявных входных данных и не имеет понятия о этапах сборки.

Scheme переменная: trivial-build-system

Эта переменная экспортируется (guix build-system trivial).

Эта система сборки требует аргумента #:builder. Этот аргумент должен быть Scheme выражением, которое строит выходные данные пакета—как с build-expression->derivation (see build-expression->derivation).