Next: Build Phases, Previous: Defining Package Variants, Up: Программный интерфейс [Contents][Index]
В каждом определении пакета указывается система сборки и аргументы для
этой системы сборки (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)
.
gnu-build-system
представляет систему сборки GNU и ее варианты
(see configuration and makefile conventions in GNU Coding Standards).
Вкратце, пакеты, использующие его, настраиваются, собираются и
устанавливаются с помощью обычной последовательности команд
./configure && make && make check && make install
. На практике часто
требуется несколько дополнительных шагов. Все эти шаги разделены на
отдельные фазы, в частности 16:
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
и
различаются в основном набором входных данных, неявно добавляемых в процесс
сборки, и списком выполняемых фаз. Некоторые из этих систем сборки
перечислены ниже.
Эта переменная экспортируется (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.
Эта переменная экспортируется (guix build-system android-ndk)
. Она
реализует процедуру сборки пакетов Android NDK (собственный комплект
разработки) с использованием процесса сборки, специфичного для Guix.
Система сборки предполагает, что пакеты устанавливают свои файлы
общедоступного интерфейса (заголовки) в подкаталог include вывода
out
, а их библиотеки - в подкаталог lib вывода out
.
Также предполагается, что объединение всех зависимостей пакета не имеет конфликтующих файлов.
В настоящее время кросс-компиляция не поддерживается, поэтому сейчас предполагается, что библиотеки и файлы заголовков являются хост-инструментами.
Эти переменные, экспортированные (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
для указания имени системы.
Эта переменная экспортируется (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.
Эта переменная экспортируется в (guix build-system copy)
. Она
поддерживает сборку простых пакетов, которые не требуют большой компиляции,
в основном просто перемещения файлов.
Она добавляет большую часть пакетов gnu-build-system
в набор входных
данных. По этой причине copy-build-system
не требуется весь
шаблонный код, часто необходимый для trivial-build-system
.
Чтобы еще больше упростить процесс установки файла, предоставляется аргумент
#:install-plan
, позволяющий упаковщику указывать, какие файлы куда
установить. План установки представляет собой список (source
target [filters])
. 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.
Эта переменная экспортируется (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
, также устанавливаются.
Эта переменная экспортируется (guix build-system cmake)
. Она
реализует процедуру сборки пакетов с использованием
инструмента сборки CMake.
Она автоматически добавляет пакет cmake
в набор входных данных.
Какой пакет используется, можно указать с помощью параметра #:cmake
.
Параметр #:configure-flags
используется как список флагов, переданных
команде cmake
. Параметр #:build-type
абстрактно определяет
флаги, передаваемые компилятору; по умолчанию используется
"RelWithDebInfo"
(сокращение от “release mode с отладочной
информацией”), что примерно означает, что код компилируется с помощью
-O2 -g
, как в случае пакетов на основе Autoconf по умолчанию.
Эта переменная экспортируется в (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
.
Эта переменная экспортируется (guix build-system go)
. Онf реализует
процедуру сборки пакетов Go с использованием стандартного
механизмов сборки Go.
Ожидается, что пользователь предоставит значение для ключа
#:import-path
и, в некоторых случаях, #:unpack-path
.
import path
соответствует пути к файловой системе, ожидаемому сценариями сборки пакета и
любыми ссылочными пакетами, и обеспечивает уникальный способ ссылки на Go
пакет. Обычно он основан на комбинации удаленного URI исходного кода пакета
и иерархической структуры файловой системы. В некоторых случаях вам нужно
будет распаковать исходный код пакета в другую структуру каталогов, отличную
от той, которая указана в пути импорта, и в таких случаях следует
использовать #:unpack-path
.
Пакеты, которые предоставляют библиотеки Go, должны устанавливать свой
исходный код во встроенные выходные данные. Ключ #:install-source?
,
который по умолчанию равен #t
, определяет, установливается ли
исходный код. Для пакетов, которые предоставляют только исполняемые файлы,
может быть установлено значение #f
.
Эта переменная экспортируется в (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
.
Эта система сборки предназначена для пакетов 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
.
Эта переменная экспортируется в (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.
Эта переменная экспортируется в (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)
, которое также экспортируется.
Эта переменная экспортируется в (guix build-system minify)
. Она
реализует процедуру минификации для простых пакетов JavaScript.
Он добавляет uglify-js
к набору входных данных и использует его для
сжатия всех файлов JavaScript в каталоге src. Другой minifier пакет
можно указать с помощью параметра #:uglify-js
, но ожидается, что этот
пакет запишет минимизированный код в стандартный вывод.
Когда не все входные файлы JavaScript находятся в каталоге src, можно
использовать параметр #:javascript-files
, чтобы указать список имен
файлов для передачи в minifier.
Эта переменная экспортируется в (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.
Эта переменная экспортируется в (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
.
Эта переменная экспортируется в (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
.
Эта переменная экспортируется в (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
.
Эта переменная экспортируется в (guix build-system r)
. Она реализует
процедуру сборки, используемую пакетами R,
которая, по сути, немного больше, чем запуск ‘R CMD INSTALL
--library=/gnu/store/…’ в среде, где R_LIBS_SITE
содержит пути
ко всем входам пакета R. Тесты запускаются после установки с использованием
R-функции tools::testInstalledPackage
.
Эта переменная экспортируется (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?
.
Эта переменная экспортируется в (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."
Эта переменная экспортируется в (guix build-system ruby)
. Она
реализует процедуру сборки RubyGems, используемую пакетами Ruby, которая
включает запуск gem build
, за которым следует gem install
.
Поле source
пакета, использующего эту систему сборки, обычно
ссылается на gem архив, поскольку это формат, который разработчики Ruby
используют при выпуске своего программного обеспечения. Система сборки
распаковывает gem архив, потенциально исправляет исходный код, запускает
набор тестов, переупаковывает gem и устанавливает его. Кроме того, на
каталоги и архивы можно ссылаться, чтобы можно было создавать unreleased
gem’ы из Git или традиционного архива с исходным кодом.
Какой пакет Ruby используется, можно указать с помощью параметра
#:ruby
. Список дополнительных флагов, передаваемых команде
gem
, можно указать с помощью параметра #:gem-flags
.
Эта переменная экспортируется в (guix build-system waf)
. Она
реализует процедуру сборки вокруг сценария waf
. Общие
этапы—configure
, build
и install
—реализуются путем
передачи их имен в качестве аргументов сценарию waf
.
Скрипт waf
выполняется интерпретатором Python. Какой пакет Python
используется для запуска сценария, можно указать с помощью параметра
#:python
.
Эта переменная экспортируется в (guix build-system scons)
. Она
реализует процедуру сборки, используемую инструментом сборки программного
обеспечения SCons. Эта система сборки запускает scons
для сборки
пакета, scons test
для запуска тестов и затем scons install
для установки пакета.
Дополнительные флаги, передаваемые в scons
, можно указать с помощью
параметра #:scons-flags
. Цели сборки и установки по умолчанию могут
быть переопределены с помощью #:build-target
и
#:install-target
соответственно. Версия Python, используемая для
запуска SCons, может быть указана путем выбора соответствующего пакета SCons
с параметром #:scons
.
Эта переменная экспортируется в (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
.
Эта переменная экспортируется в (guix build-system dub)
. Она
реализует процедуру сборки Dub, используемую пакетами D, которая включает
запуск dub build
и dub run
. Установка осуществляется путем
копирования файлов вручную.
Какой компилятор D используется, можно указать с помощью параметра
#:ldc
, который по умолчанию равен ldc
.
Эта переменная экспортируется в (guix build-system emacs)
. Она
реализует процедуру установки, аналогичную системе упаковки самого Emacs
(see Packages in The GNU Emacs Manual).
Сначала она создает файл
, а затем
байт-компилирует все файлы Emacs Lisp. В отличие от системы упаковки Emacs,
файлы документации Info перемещаются в стандартный каталог документации, а
файл dir удаляется. Файлы пакета Elisp устанавливаются
непосредственно в share/emacs/site-lisp.
package
-autoloads.el
Эта переменная экспортируется в (guix build-system font)
. Она
реализует процедуру установки для пакетов шрифтов, в которой upstream
предоставляет предварительно скомпилированные файлы TrueType, OpenType и
т.д. файлы шрифтов, которые необходимо просто скопировать на место. Она
копирует файлы шрифтов в стандартные места выходного каталога.
Эта переменная экспортируется в (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?
.
linux-module-build-system
позволяет создавать модули ядра Linux.
Эта система сборки является расширением gnu-build-system
, но со
следующими изменениями:
configure
На этой фазе среда настраивается таким образом, чтобы Makefile ядра Linux можно было использовать для сборки внешнего модуля ядра.
build
На этой фазе используется Makefile ядра Linux для сборки внешнего модуля ядра.
установка
На этой фазе используется Makefile ядра Linux для установки внешнего модуля ядра.
Возможно и полезно указать ядро Linux, которое будет использоваться для
сборки модуля (в форме arguments
пакета с использованием
linux-module-build-system
используйте ключ #:linux
, чтобы
указать это).
Эта переменная экспортируется в (guix build-system node)
. Она
реализует процедуру сборки, используемую Node.js,
которая реализует аппроксимацию команды npm install
, за которой
следует команда npm test
.
Какой пакет Node.js используется для интерпретации команд npm
, можно
указать с помощью параметра #:node
, который по умолчанию равен
node
.
Наконец, для пакетов, которым не нужно ничего столь же сложного, предоставляется “trivial” система сборки. Она тривиальна в том смысле, что она практически не оказывает поддержки при сборке: она не извлекает никаких неявных входных данных и не имеет понятия о этапах сборки.
Эта переменная экспортируется (guix build-system trivial)
.
Эта система сборки требует аргумента #:builder
. Этот аргумент должен
быть Scheme выражением, которое строит выходные данные пакета—как с
build-expression->derivation
(see build-expression->derivation
).
Please see the (guix build
gnu-build-system)
modules for more details about the build phases.
Next: Build Phases, Previous: Defining Package Variants, Up: Программный интерфейс [Contents][Index]