Next: origin
Справка, Up: Описание пакетов [Contents][Index]
package
СсылкаВ этом разделе перечислены все параметры, доступные в объявлениях
package
(see Описание пакетов).
Это тип данных, представляющий рецепт пакета.
name
Название пакета в виде строки.
версия
The version of the package, as a string. See Номера версий, for guidelines.
источник
Объект, указывающий, как должен быть получен исходный код пакета. В
большинстве случаев это объект origin
, который обозначает файл,
полученный из Интернета (see origin
Справка). Это также может быть
любой другой объект, подобный файлу, например local-file
, который
представляет собой файл из локальной файловой системы (see local-file
).
система сборки
Система сборки, которую следует использовать для сборки пакета (see Системы сборки).
arguments
(default: '()
)The arguments that should be passed to the build system (see Системы сборки). This is a list, typically containing sequential keyword-value pairs, as in this example:
(package
(name "example")
;; several fields omitted
(arguments
(list #:tests? #f ;skip tests
#:make-flags #~'("VERBOSE=1") ;pass flags to 'make'
#:configure-flags #~'("--enable-frobbing"))))
The exact set of supported keywords depends on the build system
(see Системы сборки), but you will find that almost all of them honor
#:configure-flags
, #:make-flags
, #:tests?
, and
#:phases
. The #:phases
keyword in particular lets you modify
the set of build phases for your package (see Фазы сборки).
inputs
(default: '()
) ¶native-inputs
(default: '()
)propagated-inputs
(default: '()
)These fields list dependencies of the package. Each element of these lists is either a package, origin, or other “file-like object” (see G-Expressions); to specify the output of that file-like object that should be used, pass a two-element list where the second element is the output (see Пакеты со множественным выходом, for more on package outputs). For example, the list below specifies three inputs:
(list libffi libunistring `(,glib "bin")) ;the "bin" output of GLib
In the example above, the "out"
output of libffi
and
libunistring
is used.
Compatibility Note: Until version 1.3.0, input lists were a list of tuples, where each tuple has a label for the input (a string) as its first element, a package, origin, or derivation as its second element, and optionally the name of the output thereof that should be used, which defaults to
"out"
. For example, the list below is equivalent to the one above, but using the old input style:;; Old input style (deprecated). `(("libffi" ,libffi) ("libunistring" ,libunistring) ("glib:bin" ,glib "bin")) ;the "bin" output of GLibThis style is now deprecated; it is still supported but support will be removed in a future version. It should not be used for new package definitions. See Invoking
guix style
, on how to migrate to the new style.
Различие между native-inputs
и inputs
необходимо при
рассмотрении кросс-компиляции. При кросс-компиляции зависимости,
перечисленные в input
, создаются для архитектуры target; и
наоборот, зависимости, перечисленные в native-inputs
, созданы для
архитектуры машины, выполняющей сборку.
native-inputs
обычно используется для перечисления инструментов,
необходимых во время сборки, но не во время выполнения, таких как Autoconf,
Automake, pkg-config, Gettext или Bison. guix lint
может сообщить
о вероятных ошибках в этой области (see Вызов guix lint
).
Наконец, propagated-inputs
похоже на inputs
, но указанные
пакеты будут автоматически установлены в профили (see the role
of profiles in Guix) вместе с пакетом, которому они принадлежат
(see guix package
, for
information on how guix package
deals with propagated inputs).
Например, это необходимо при упаковке библиотеки C/C++, которой для
компиляции требуются заголовки другой библиотеки, или когда файл pkg-config
ссылается на другое поле через его Requires
.
Другой пример использования propagated-inputs
- это языки, в которых
отсутствует возможность записывать путь поиска во время выполнения,
аналогичный RUNPATH
файлов ELF; сюда входят Guile, Python, Perl и
другие. При упаковке библиотек, написанных на этих языках, убедитесь, что
они могут найти код библиотеки, от которого они зависят, во время
выполнения, указав зависимости времени выполнения в
propagated-inputs
, а не в inputs
.
outputs
(default: '("out")
)Список выходных имен пакета. See Пакеты со множественным выходом, для типичного использования дополнительных выходов.
native-search-paths
(default: '()
)search-paths
(по умолчанию: '()
)A list of search-path-specification
objects describing search-path
environment variables honored by the package. See Search Paths, for more
on search path specifications.
As for inputs, the distinction between native-search-paths
and
search-paths
only matters when cross-compiling. In a
cross-compilation context, native-search-paths
applies exclusively to
native inputs whereas search-paths
applies only to host inputs.
Packages such as cross-compilers care about target inputs—for instance,
our (modified) GCC cross-compiler has CROSS_C_INCLUDE_PATH
in
search-paths
, which allows it to pick .h files for the target
system and not those of native inputs. For the majority of packages
though, only native-search-paths
makes sense.
replacement
(по умолчанию: #f
)Это должен быть либо #f
, либо объект пакета, который будет
использоваться как замена для этого пакета. See grafts, чтобы узнать подробности.
синопсис
Описание пакета в одну строку.
описание
A more elaborate description of the package, as a string in Texinfo syntax.
лицензия
¶Лицензия пакета; значение из (guix licenses)
или список таких
значений.
главная страница
URL-адрес домашней страницы пакета в виде строки.
port
(default: 22
)Список систем, поддерживаемых пакетом, в виде строк вида
architecture-kernel
, например "x86_64-linux"
.
location
(по умолчанию: исходное местоположение формы package
)Исходное расположение пакета. Это полезно переопределить при наследовании от другого пакета, и в этом случае это поле не корректируется автоматически.
При использовании в lexical scope определения поля пакета этот идентификатор преобразуется в определяемый пакет.
В приведенном ниже примере показано, как добавить пакет в качестве собственного ввода при кросс-компиляции:
(package
(name "guile")
;; ...
;; When cross-compiled, Guile, for example, depends on
;; a native version of itself. Add it here.
(native-inputs (if (%current-target-system)
(list this-package)
'())))
Ссылка на this-package
вне определения пакета является ошибкой.
The following helper procedures are provided to help deal with package inputs.
Look up name among package’s inputs (or native, propagated, or
direct inputs). Return it if found, #f
otherwise.
name is the name of a package depended on. Here’s how you might use it:
(use-modules (guix packages) (gnu packages base)) (lookup-package-direct-input coreutils "gmp") ⇒ #<package gmp@6.2.1 …>
In this example we obtain the gmp
package that is among the direct
inputs of coreutils
.
Sometimes you will want to obtain the list of inputs needed to
develop a package—all the inputs that are visible when the package
is compiled. This is what the package-development-inputs
procedure
returns.
package for development purposes on system. When target
is true, return the inputs needed to cross-compile package from
system to target, where target is a triplet such as
"aarch64-linux-gnu"
.
Note that the result includes both explicit inputs and implicit
inputs—inputs automatically added by the build system (see Системы сборки). Let us take the hello
package to illustrate that:
(use-modules (gnu packages base) (guix packages)) hello ⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790> (package-direct-inputs hello) ⇒ () (package-development-inputs hello) ⇒ (("source" …) ("tar" #<package tar@1.32 …>) …)
In this example, package-direct-inputs
returns the empty list,
because hello
has zero explicit dependencies. Conversely,
package-development-inputs
includes inputs implicitly added by
gnu-build-system
that are required to build hello
: tar, gzip,
GCC, libc, Bash, and more. To visualize it, guix graph hello
would show you explicit inputs, whereas guix graph -t bag hello
would include implicit inputs (see Вызов guix graph
).
Поскольку пакеты являются обычными Scheme объектами, которые захватывают полный граф зависимостей и связанные процедуры сборки, часто бывает полезно написать процедуры, которые принимают пакет и возвращают его измененную версию в соответствии с некоторыми параметрами. Ниже приведены несколько примеров.
Вернуть вариант package, в котором используется toolchain вместо
стандартного набора инструментов GNU C/C++. toolchain должен быть
списком входов (кортежи меток/пакетов), обеспечивающих эквивалентную
функциональность, например, пакет gcc-toolchain
.
Пример ниже возвращает вариант пакета hello
, созданный с помощью
GCC 10.x и остальной части GNU утилит (Binutils и библиотеки GNU C)
вместо цепочки инструментов по умолчанию:
(let ((toolchain (specification->package "gcc-toolchain@10")))
(package-with-c-toolchain hello `(("toolchain" ,toolchain))))
Инструменты сборки являются частью неявных входных данных пакетов - обычно они не указываются как часть различных полей “входных данных”, а вместо этого извлекается системой сборки. Следовательно, эта процедура работает путем изменения системы сборки package, так что она использует toolchain вместо значений по умолчанию. Системы сборки, чтобы узнать больше о системах сборки.
Next: origin
Справка, Up: Описание пакетов [Contents][Index]