Next: Фазы сборки, Previous: Writing Manifests, 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. На практике часто
требуется несколько дополнительных шагов. Все эти шаги разбиты на отдельные
фазы. See Фазы сборки, чтобы узнать больше о фазах сборки и
способах их настройки.
Кроме того, эта система сборки гарантирует, что доступна “стандартная”
среда для пакетов GNU. Сюда входят такие инструменты, как GCC, libc,
Coreutils, Bash, Make, Diffutils, grep и sed (полный список см. в модуле
(guix build-system gnu)). Мы называем их неявными входами
пакета, потому что в определениях пакетов они не упоминаются.
Эта система сборки поддерживает ряд ключевых аргументов, которые можно
передать через поле arguments пакета. Вот некоторые из основных
параметров:
build phasesСчитать список каналов из файла file вместо ~/.config/guix/channels.scm. file должен содержать код Scheme, который определяет список объектов "канал". См. See Каналы для подробной информации.
Конфигурирование системыЭто список флагов (строк), переданных в сценарий (script)
configure. См. See Описание пакетов.
#:make-flagsЭтот список строк содержит флаги, передаваемые в качестве аргументов для
вызовов make на этапах build, check и
install.
#:out-of-source?Это логическое значение, #f по умолчанию, указывает, следует ли
запускать сборки в каталоге сборки отдельно от исходников.
Когда это значение истинно, на этапе configure создается отдельный
каталог сборки, происходит переход в этот каталог и оттуда запускается
сценарий configure. Это полезно для пакетов, которым это необходимо,
таких как glibc.
#:tests?This Boolean, #t by default, indicates whether the check phase
should run the package’s test suite.
#:test-targetThis string, "check" by default, gives the name of the makefile
target used by the check phase.
#:parallel-build?#:parallel-tests?These Boolean values specify whether to build, respectively run the test
suite, in parallel, with the -j flag of make. When they
are true, make is passed -jn, where n is the
number specified as the --cores option of guix-daemon or
that of the guix client command (see --cores).
#:validate-runpath?This Boolean, #t by default, determines whether to “validate” the
RUNPATH of ELF binaries (.so shared libraries as well as
executables) previously installed by the install phase.
See the validate-runpath phase, for
details.
#:substitutable?This Boolean, #t by default, tells whether the package outputs should
be substitutable—i.e., whether users should be able to obtain substitutes
for them instead of building locally (see Подстановки).
--references--referencesWhen true, these arguments must be a list of dependencies that must not appear among the references of the build results. If, upon build completion, some of these references are retained, the build process fails.
This is useful to ensure that a package does not erroneously keep a
reference to some of it build-time inputs, in cases where doing so would,
for example, unnecessarily increase its size (see Вызов guix size).
Most other build systems support these keyword arguments.
Другие объекты <build-system> определены для поддержки других
соглашений и инструментов, используемых пакетами свободного программного
обеспечения. Они наследуют большую часть gnu-build-system и
различаются в основном набором входных данных, неявно добавляемых в процесс
сборки, и списком выполняемых фаз. Некоторые из этих систем сборки
перечислены ниже.
This variable is exported by (guix build-system agda). It implements
a build procedure for Agda libraries.
It adds agda to the set of inputs. A different Agda can be specified
with the #:agda key.
The #:plan key is a list of cons cells (regexp
. parameters), where regexp is a regexp that should match the
.agda files to build, and parameters is an optional list of
parameters that will be passed to agda when type-checking it.
When the library uses Haskell to generate a file containing all imports, the
convenience #:gnu-and-haskell? can be set to #t to add
ghc and the standard inputs of gnu-build-system to the input
list. You will still need to manually add a phase or tweak the
'build phase, as in the definition of agda-stdlib.
Эта переменная экспортируется (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 (see Модули Python), с использованием префикса cl-.
Для создания исполняемых программ и образов можно использовать процедуры
сборки 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.
This variable is exported by (guix build-system chicken). It builds
CHICKEN Scheme modules, also called “eggs” or
“extensions”. CHICKEN generates C source code, which then gets compiled
by a C compiler, in this case GCC.
Эта система сборки добавляет chicken к входным данным (inputs)
пакета, а также к пакетам gnu-build-system.
The build system can’t (yet) deduce the egg’s name automatically, so just
like with go-build-system and its #:import-path, you should
define #:egg-name in the package’s arguments field.
Например, если вы создаете пакет, содержащий Bash, с помощью:
(arguments '(#:egg-name "srfi-1"))
Egg dependencies must be defined in propagated-inputs, not
inputs because CHICKEN doesn’t embed absolute references in compiled
eggs. Test dependencies should go to native-inputs, as usual.
Эта переменная экспортируется в (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 установить все файлы, кроме тех, которые соответствуют
фильтрам исключения. Если указаны и включения, и исключения, то исключения
выполняются поверх включений.
#:output argument
can be used to specify which output label the files should be installed to.
В любом случае пути, относительные к 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.
("foo/doc" "share/my-app/doc" #:output "doc"): Install
"foo/doc" to "share/my-app/doc" within the "doc"
output.
This variable is exported by (guix build-system vim). It is an
extension of the copy-build-system, installing Vim and Neovim plugins
into locations where these two text editors know to find their plugins,
using their packpaths.
Packages which are prefixed with vim- will be installed in Vim’s
packpath, while those prefixed with neovim- will be installed in
Neovim’s packpath. If there is a doc directory with the plugin then
helptags will be generated automatically.
There are a couple of keywords added with the vim-build-system:
plugin-name it is possible to set the name of the plugin.
While by default this is set to the name and version of the package, it is
often more helpful to set this to name which the upstream author calls their
plugin. This is the name used for :packadd from inside Vim.
install-plan it is possible to augment the built-in
install-plan of the vim-build-system. This is particularly helpful
if you have files which should be installed in other locations. For more
information about using the install-plan, see the
copy-build-system (see copy-build-system).
#:vim it is possible to add this package to Vim’s packpath,
in addition to if it is added automatically because of the vim-
prefix in the package’s name.
#:neovim it is possible to add this package to Neovim’s
packpath, in addition to if it is added automatically because of the
neovim- prefix in the package’s name.
#:mode it is possible to adjust the path which the plugin is
installed into. By default the plugin is installed into start and
other options are available, including opt. Adding a plugin into
opt will mean you will need to run, for example, :packadd
foo to load the foo plugin from inside of Vim.
Эта переменная экспортируется (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? определяет,
нужно ли запускать тесты.
installНа этом этапе устанавливаются все созданные ранее 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 по умолчанию.
This variable is exported by (guix build-system composer). It
implements the build procedure for packages using
Composer, the PHP package manager.
It automatically adds the php package to the set of inputs. Which
package is used can be specified with the #:php parameter.
The #:test-target parameter is used to control which script is run
for the tests. By default, the test script is run if it exists. If
the script does not exist, the build system will run phpunit from the
source directory, assuming there is a phpunit.xml file.
Эта переменная экспортируется в (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.
This variable is exported by (guix build-system elm). It implements
a build procedure for Elm packages similar to
‘elm install’.
The build system adds an Elm compiler package to the set of inputs. The
default compiler package (currently elm-sans-reactor) can be
overridden using the #:elm argument. Additionally, Elm packages
needed by the build system itself are added as implicit inputs if they are
not already present: to suppress this behavior, use the
#:implicit-elm-package-inputs? argument, which is primarily useful
for bootstrapping.
The "dependencies" and "test-dependencies" in an Elm package’s
elm.json file correspond to propagated-inputs and
inputs, respectively.
Elm requires a particular structure for package names: see Пакеты Elm
for more details, including utilities provided by (guix build-system
elm).
There are currently a few noteworthy limitations to elm-build-system:
{ "type": "package" } in their
elm.json files. Using elm-build-system to build Elm
applications (which declare { "type": "application" }) is
possible, but requires ad-hoc modifications to the build phases. For
examples, see the definitions of the elm-todomvc example application
and the elm package itself (because the front-end for the ‘elm
reactor’ command is an Elm application).
ELM_HOME, but this does not yet work well with
elm-build-system. This limitation primarily affects Elm
applications, because they specify exact versions for their dependencies,
whereas Elm packages specify supported version ranges. As a workaround, the
example applications mentioned above use the
patch-application-dependencies procedure provided by (guix
build elm-build-system) to rewrite their elm.json files to refer to
the package versions actually present in the build environment.
Alternatively, Guix package transformations (see Defining Package Variants) could be used to rewrite an application’s entire dependency
graph.
elm-test-rs nor
the Node.js-based elm-test runner has been packaged for Guix yet.
Эта переменная экспортируется (guix build-system go). Онf реализует
процедуру сборки пакетов Go с использованием стандартного
механизмов сборки Go.
Ожидается, что пользователь предоставит значение для ключа
#:import-path и, в некоторых случаях, #:unpack-path.
import path
соответствует пути к файловой системе, ожидаемому сценариями сборки пакета и
любыми ссылочными пакетами, и обеспечивает уникальный способ ссылки на Go
пакет. Обычно он основан на комбинации удаленного URI исходного кода пакета
и иерархической структуры файловой системы. В некоторых случаях вам нужно
будет распаковать исходный код пакета в другую структуру каталогов, отличную
от той, которая указана в пути импорта, и в таких случаях следует
использовать #:unpack-path.
Пакеты, которые предоставляют библиотеки Go, должны устанавливать свой
исходный код во встроенные выходные данные. Ключ #:install-source?,
который по умолчанию равен #t, определяет, установливается ли
исходный код. Для пакетов, которые предоставляют только исполняемые файлы,
может быть установлено значение #f.
Packages can be cross-built, and if a specific architecture or operating
system is desired then the keywords #:goarch and #:goos can be
used to force the package to be built for that architecture and operating
system. The combinations known to Go can be found
in their
documentation.
The key #:go can be used to specify the Go compiler package with
which to build the package.
The phase check provides a wrapper for go test which builds a
test binary (or multiple binaries), vets the code and then runs the test
binary. Build, test and test binary flags can be provided as
#:test-flags parameter, default is '(). See go help
test and go help testflag for more details.
The key #:embed-files, default is '(), provides a list of
future embedded files or regexps matching files. They will be copied to
build directory after unpack phase. See
https://pkg.go.dev/embed for more details.
Эта переменная экспортируется в (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.
The Julia package name and uuid is read from the file Project.toml.
These values can be overridden by passing the argument
#:julia-package-name (which must be correctly capitalized) or
#:julia-package-uuid.
Julia packages usually manage their binary dependencies via
JLLWrappers.jl, a Julia package that creates a module (named after
the wrapped library followed by _jll.jl.
To add the binary path _jll.jl packages, you need to patch the files
under src/wrappers/, replacing the call to the macro
JLLWrappers.@generate_wrapper_header, adding as a second argument
containing the store path the binary.
As an example, in the MbedTLS Julia package, we add a build phase (see Фазы сборки) to insert the absolute file name of the wrapped MbedTLS package:
(add-after 'unpack 'override-binary-path
(lambda* (#:key inputs #:allow-other-keys)
(for-each (lambda (wrapper)
(substitute* wrapper
(("generate_wrapper_header.*")
(string-append
"generate_wrapper_header(\"MbedTLS\", \""
(assoc-ref inputs "mbedtls") "\")\n"))))
;; There's a Julia file for each platform, override them all.
(find-files "src/wrappers/" "\\.jl$"))))
Some older packages that aren’t using Project.toml yet, will require
this file to be created, too. It is internally done if the arguments
#:julia-package-name and #:julia-package-uuid are provided.
Эта переменная экспортируется в (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), которое также экспортируется.
This variable is exported by (guix build-system minetest). It
implements a build procedure for Minetest
mods, which consists of copying Lua code, images and other resources to the
location Minetest searches for mods. The build system also minimises PNG
images and verifies that Minetest can load the mod without errors.
Эта переменная экспортируется в (guix build-system minify). Она
реализует процедуру минификации для простых пакетов JavaScript.
Он добавляет uglify-js к набору входных данных и использует его для
сжатия всех файлов JavaScript в каталоге src. Другой minifier пакет
можно указать с помощью параметра #:uglify-js, но ожидается, что этот
пакет запишет минимизированный код в стандартный вывод.
Когда не все входные файлы JavaScript находятся в каталоге src, можно
использовать параметр #:javascript-files, чтобы указать список имен
файлов для передачи в minifier.
This variable is exported by (guix build-system mozilla). It sets
the --target and --host configuration flags to what software
developed by Mozilla expects – due to historical reasons, Mozilla software
expects --host to be the system that is cross-compiled from and
--target to be the system that is cross-compiled to, contrary to the
standard Autotools conventions.
Эта переменная экспортируется в (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/….
For packages that install stand-alone Python programs under bin/, it
takes care of wrapping these programs so that their GUIX_PYTHONPATH
environment variable points to all the Python libraries they depend on.
Какой пакет Python используется для сборки, можно указать с помощью
параметра #:python. Это полезный способ принудительно создать пакет
для определенной версии интерпретатора Python, что может потребоваться, если
пакет совместим только с одной версией интерпретатора.
По умолчанию guix вызывает setup.py под управлением
setuptools, как и pip. Некоторые пакеты несовместимы с
setuptools (и pip), поэтому вы можете отключить это, установив для параметра
#:use-setuptools? значение #f.
If a "python" output is available, the package is installed into it
instead of the default "out" output. This is useful for packages that
include a Python package as only a part of the software, and thus want to
combine the phases of python-build-system with another build system.
Python bindings are a common usecase.
This is a variable exported by guix build-system pyproject. It is
based on python-build-system, and adds support for
pyproject.toml and PEP 517.
It also supports a variety of build backends and test frameworks.
The API is slightly different from python-build-system:
#:use-setuptools? and #:test-target is removed.
#:configure-flags is changed. Instead of a list this option must be a
JSON object, whose interpretation depends on the build backend. For instance
the example from PEP
517 should be written as '(@ ("CC" "gcc") ("--global-option"
("--some-global-option")) ("--build-option" ("--build-option1"
"--build-option2")))
#:backend-path is added. It defaults to #false, but when set
to a list it will be appended to Python’s search path and overrides the
definition in pyproject.toml.
#:build-backend is added. It defaults to #false and will try
to guess the appropriate backend based on pyproject.toml.
#:test-backend is added. It defaults to #false and will guess
an appropriate test backend based on what is available in package inputs.
#:test-flags is added. The default is '(). These flags are
passed as arguments to the test command. Note that flags for verbose output
is always enabled on supported backends.
It is considered “experimental” in that the implementation details are not set in stone yet, however users are encouraged to try it for new Python projects (even those using setup.py). The API is subject to change, but any breaking changes in the Guix channel will be dealt with.
Eventually this build system will be deprecated and merged back into python-build-system, probably some time in 2024.
Эта переменная экспортируется в (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 python). Она
реализует более или менее стандартную процедуру сборки, используемую
пакетами Python, которая заключается в запуске python setup.py build,
а затем python setup.py install --prefix=/gnu/store/….
It further creates a wrapper script in bin/ and a desktop entry in
share/applications, both of which can be used to launch the game.
Which Ren’py package is used can be specified with #:renpy. Games
can also be installed in outputs other than “out” by using
#:output.
Эта переменная экспортируется в (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; двоичные файлы,
библиотеки и ресурсы; помещает файлы в bin/. Тесты можно пропустить,
передав #f параметру tests?.
Какой пакет rakudo используется, можно указать с помощью rakudo.
Какой пакет perl6-tap-harness, используемый для тестов, можно указать с
помощью #:verify6 или удалить, передав #f в параметр
with-verify6?. Какой пакет perl6-zef, используемый для тестирования
и установки, можно указать с помощью #:zef или удалить, передав
#f в параметр with-zef?.
This variable is exported by (guix build-system rebar). It
implements a build procedure around rebar3, a
build system for programs written in the Erlang language.
It adds both rebar3 and the erlang to the set of inputs.
Different packages can be specified with the #:rebar and
#:erlang parameters, respectively.
This build system is based on gnu-build-system, but with the
following phases changed:
unpackThis phase, after unpacking the source like the gnu-build-system
does, checks for a file contents.tar.gz at the top-level of the
source. If this file exists, it will be unpacked, too. This eases handling
of package hosted at https://hex.pm/, the Erlang and Elixir package
repository.
bootstrapconfigureThere are no bootstrap and configure phase because erlang
packages typically don’t need to be configured.
buildThis phase runs rebar3 compile with the flags listed in
#:rebar-flags.
checkUnless #:tests? #f is passed, this phase runs rebar3 eunit, or
some other target specified with #:test-target, with the flags listed
in #:rebar-flags,
installThis installs the files created in the default profile, or some other
profile specified with #:install-profile.
Эта переменная экспортируется в (guix build-system texlive). Она
используется для сборки пакетов TeX в batch режиме с указанным движком.
Система сборки устанавливает переменную TEXINPUTS для поиска всех
исходных файлов TeX во входных данных.
By default it tries to run luatex on all .ins files, and if it
fails to find any, on all .dtx files. A different engine and format
can be specified with, respectively, the #:tex-engine and
#:tex-format arguments. Different build targets can be specified
with the #:build-targets argument, which expects a list of file
names.
It also generates font metrics (i.e., .tfm files) out of Metafont
files whenever possible. Likewise, it can also create TeX formats (i.e.,
.fmt files) listed in the #:create-formats argument, and
generate a symbolic link from bin/ directory to any script located in
texmf-dist/scripts/, provided its file name is listed in
#:link-scripts argument.
The build system adds texlive-bin from (gnu packages tex) to
the native inputs. It can be overridden with the #:texlive-bin
argument.
The package texlive-latex-bin, from the same module, contains most of
the tools for building TeX Live packages; for convenience, it is also added
by default to the native inputs. However, this can be troublesome when
building a dependency of texlive-latex-bin itself. In this
particular situation, the #:texlive-latex-bin? argument should be set
to #f.
Эта переменная экспортируется в (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.
This variable is exported by (guix build-system zig). It implements
the build procedures for the Zig build system
(zig build command).
Selecting this build system adds zig to the package inputs, in
addition to the packages of gnu-build-system.
There is no configure phase because Zig packages typically do not
need to be configured. The #:zig-build-flags parameter is a list of
flags that are passed to the zig command during the build. The
#:zig-test-flags parameter is a list of flags that are passed to the
zig test command during the check phase. The default compiler
package can be overridden with the #:zig argument.
The optional zig-release-type parameter declares the type of
release. Possible values are: safe, fast, or
small. The default value is #f, which causes the release flag
to be omitted from the zig command. That results in a debug
build.
Эта переменная экспортируется в (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).
Сначала она создает файл package-autoloads.el
Эта переменная экспортируется в (guix build-system font). Она
реализует процедуру установки для пакетов шрифтов, в которой upstream
предоставляет предварительно скомпилированные файлы TrueType, OpenType и
т.д. файлы шрифтов, которые необходимо просто скопировать на место. Она
копирует файлы шрифтов в стандартные места выходного каталога.
Эта переменная экспортируется в (guix build-system meson). Она
реализует процедуру сборки для пакетов, которые используют
Meson в качестве своей системы сборки.
Она добавляет к набору входов как Meson, так и
Ninja, при необходимости их можно изменить
с помощью параметров #:meson и #:ninja.
Эта система сборки является расширением gnu-build-system, но со
следующими фазами, измененными на некоторые специфичные для Meson:
configureНа этапе выполняется meson с флагами, указанными в
#:configure-flags. Флаг --buildtype всегда установлен на
debugoptimized, если что-то еще не указано в #:build-type.
buildНа этапе выполняется ninja для параллельной сборки пакета по
умолчанию, но это можно изменить с помощью #:parallel-build?.
checkThe phase runs ‘meson test’ with a base set of options that cannot be
overridden. This base set of options can be extended via the
#:test-options argument, for example to select or skip a specific
test suite.
installФаза выполняется ninja install и не может быть изменен.
Помимо этого, система сборки также добавляет следующие фазы:
fix-runpathThis phase ensures that all binaries can find the libraries they need. It
searches for required libraries in subdirectories of the package being
built, and adds those to RUNPATH where needed. It also removes
references to libraries left over from the build phase by meson, such
as test dependencies, that aren’t actually required for the program to run.
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 для сборки внешнего модуля ядра.
installНа этой фазе используется Makefile ядра Linux для установки внешнего модуля ядра.
Возможно и полезно указать ядро Linux, которое будет использоваться для
сборки модуля (в форме arguments пакета с использованием
linux-module-build-system используйте ключ #:linux, чтобы
указать это).
Эта переменная экспортируется в (guix build-system node). Она
реализует процедуру сборки, используемую Node.js,
которая реализует аппроксимацию команды npm install, за которой
следует команда npm test.
Какой пакет Node.js используется для интерпретации команд npm, можно
указать с помощью параметра #:node, который по умолчанию равен
node.
This variable is exported by (guix build-system tree-sitter). It
implements procedures to compile grammars for the
Tree-sitter parsing
library. It essentially runs tree-sitter generate to translate
grammar.js grammars to JSON and then to C. Which it then compiles to
native code.
Tree-sitter packages may support multiple grammars, so this build system
supports a #:grammar-directories keyword to specify a list of
locations where a grammar.js file may be found.
Grammars sometimes depend on each other, such as C++ depending on C and TypeScript depending on JavaScript. You may use inputs to declare such dependencies.
Наконец, для пакетов, которым не нужно ничего столь же сложного, предоставляется “trivial” система сборки. Она тривиальна в том смысле, что она практически не оказывает поддержки при сборке: она не извлекает никаких неявных входных данных и не имеет понятия о этапах сборки.
Эта переменная экспортируется (guix build-system trivial).
Эта система сборки требует аргумента #:builder. Этот аргумент должен
быть Scheme выражением, которое строит выходные данные пакета—как с
build-expression->derivation (see build-expression->derivation).
This variable is exported by (guix build-system channel).
This build system is meant primarily for internal use. A package using this
build system must have a channel specification as its source field
(see Каналы); alternatively, its source can be a directory name, in
which case an additional #:commit argument must be supplied to
specify the commit being built (a hexadecimal string).
Optionally, a #:channels argument specifying additional channels can
be provided.
The resulting package is a Guix instance of the given channel(s), similar to
how guix time-machine would build it.
Next: Фазы сборки, Previous: Writing Manifests, Up: Программный интерфейс [Contents][Index]