Next: , Previous: , Up: Программный интерфейс   [Contents][Index]


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. На практике часто требуется несколько дополнительных шагов. Все эти шаги разбиты на отдельные фазы. See Фазы сборки, чтобы узнать больше о фазах сборки и способах их настройки.

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

This build system supports a number of keyword arguments, which can be passed via the arguments field of a package. Here are some of the main parameters:

#:phases

This argument specifies build-side code that evaluates to an alist of build phases. See Фазы сборки, for more information.

#:configure-flags

This is a list of flags (strings) passed to the configure script. See Описание пакетов, for an example.

#:make-flags

This list of strings contains flags passed as arguments to make invocations in the build, check, and install phases.

#:out-of-source?

This Boolean, #f by default, indicates whether to run builds in a build directory separate from the source tree.

When it is true, the configure phase creates a separate build directory, changes to that directory, and runs the configure script from there. This is useful for packages that require it, such as glibc.

#:tests?

This Boolean, #t by default, indicates whether the check phase should run the package’s test suite.

#:test-target

This 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.

This validation step consists in making sure that all the shared libraries needed by an ELF binaries, which are listed as DT_NEEDED entries in its PT_DYNAMIC segment, appear in the DT_RUNPATH entry of that binary. In other words, it ensures that running or using those binaries will not result in a “file not found” error at run time. See -rpath in The GNU Linker, for more information on RUNPATH.

#: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 Подстановки).

#:allowed-references
#:disallowed-references

When 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 и различаются в основном набором входных данных, неявно добавляемых в процесс сборки, и списком выполняемых фаз. Некоторые из этих систем сборки перечислены ниже.

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.

The #:main-class parameter can be used with the minimal ant buildfile to specify the main class of the resulting jar. This makes the jar file executable. The #:test-include parameter can be used to specify the list of junit tests to run. It defaults to (list "**/*Test.java"). The #:test-exclude can be used to disable some tests. It defaults to (list "**/Abstract*.java"), because abstract classes cannot be run as tests.

Параметр #: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

These variables, exported by (guix build-system asdf), implement build procedures for Common Lisp packages using “ASDF”. ASDF is a system definition facility for Common Lisp programs and libraries.

The asdf-build-system/source system installs the packages in source form, and can be loaded using any common lisp implementation, via ASDF. The others, such as asdf-build-system/sbcl, install binary systems in the format which a particular implementation understands. These build systems can also be used to produce executable programs, or lisp images which contain a set of packages pre-loaded.

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

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

In order to create executable programs and images, the build-side procedures build-program and build-image can be used. They should be called in a build phase after the create-asdf-configuration phase, so that the system which was just built can be used within the resulting image. build-program requires a list of Common Lisp expressions to be passed as the #:entry-program argument.

By default, all the .asd files present in the sources are read to find system definitions. The #:asd-files parameter can be used to specify the list of .asd files to read. Furthermore, if the package defines a system for its tests in a separate file, it will be loaded before the tests are run if it is specified by the #:test-asd-file parameter. If it is not set, the files <system>-tests.asd, <system>-test.asd, tests.asd, and test.asd will be tried if they exist.

If for some reason the package must be named in a different way than the naming conventions suggest, or if several systems must be compiled, the #:asd-systems parameter can be used to specify the list of system names.

Scheme Variable: cargo-build-system

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

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

Regular cargo dependencies should be added to the package definition similarly to other packages; those needed only at build time to native-inputs, others to inputs. If you need to add source-only crates then you should add them to via the #:cargo-inputs parameter as a list of name and spec pairs, where the spec can be a package or a source definition. Note that the spec must evaluate to a path to a gzipped tarball which includes a Cargo.toml file at its root, or it will be ignored. Similarly, cargo dev-dependencies should be added to the package definition via the #:cargo-development-inputs parameter.

In its configure phase, this build system will make any source inputs specified in the #:cargo-inputs and #:cargo-development-inputs parameters available to cargo. It will also remove an included Cargo.lock file to be recreated by cargo during the build phase. The package phase will run cargo package to create a source crate for future use. The install phase installs the binaries defined by the crate. Unless install-source? #f is defined it will also install a source crate repository of itself and unpacked sources, to ease in future hacking on rust packages.

Scheme Variable: chicken-build-system

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.

For example, if you are packaging the srfi-1 egg:

(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.

Scheme Variable: copy-build-system

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

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

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

Примеры:

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

This variable is exported by (guix build-system julia). It implements the build procedure used by julia packages, which essentially is similar to running ‘julia -e 'using Pkg; Pkg.add(package)'’ in an environment where JULIA_LOAD_PATH contains the paths to all Julia package inputs. Tests are run by calling /test/runtests.jl.

The Julia package name is read from the file Project.toml. This value can be overridden by passing the argument #:julia-package-name (which must be correctly capitalized).

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-apache") "\")\n"))))
              ;; There's a Julia file for each platform, override them all.
              (find-files "src/wrappers/" "\\.jl$"))))

Some older packages that aren’t using Package.toml yet, will require this file to be created, too. The function julia-create-package-toml helps creating the file. You need to pass the outputs and the source of the package, it’s name (the same as the file-name parameter), the package uuid, the package version, and a list of dependencies specified by their name and their 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 Variable: renpy-build-system

This variable is exported by (guix build-system renpy). It implements the more or less standard build procedure used by Ren’py games, which consists of loading #:game once, thereby creating bytecode for it.

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.

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; двоичные файлы, библиотеки и ресурсы; помещает файлы в 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).


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]