Next: Fases de construcción, Previous: Writing Manifests, Up: Interfaz programática [Contents][Index]
Cada definición de paquete especifica un sistema de construcción y
parámetros para dicho sistema de construcción (see Definición de paquetes). Este campo build-system representa el procedimiento de
construcción del paquete, así como las dependencias implícitas de dicho
procedimiento de construcción.
Los sistemas de construcción son objetos <build-system>. La interfaz
para crear y manipularlos se proporciona en el módulo (guix
build-system), y otros módulos exportan sistemas de construcción reales.
En su implementación, los sistemas de construcción primero compilan los
objetos package a objetos bag. Una bolsa (traducción de bag) es
como un paquete, pero con menos ornamentos—en otras palabras, una bolsa es
una representación a un nivel más bajo de un paquete, que contiene todas las
entradas de dicho paquete, incluyendo algunas implícitamente añadidas por el
sistema de construcción. Esta representación intermedia se compila entonces
a una derivación (see Derivaciones). EL procedimiento
package-with-c-toolchain es un ejemplo de una forma de cambiar las
entradas implícitas que el sistema de construcción del paquete incluye
(see package-with-c-toolchain).
Los sistemas de construcción aceptan una lista opcional de
parámetros. En las definiciones de paquete, estos son pasados vía
el campo arguments (see Definición de paquetes). Normalmente son
parámetros con palabras clave (see keyword arguments
in Guile in GNU Guile Reference Manual). El valor de estos parámetros
normalmente se evalúa en la capa de construcción—es decir, por un
proceso Guile lanzado por el daemon (see Derivaciones).
El sistema de construcción principal es gnu-build-system, el cual
implementa el procedimiento estándar de construcción para GNU y muchos otros
paquetes. Se proporciona por el módulo (guix build-system gnu).
gnu-build-system representa el sistema de construcción GNU y sus variantes (see configuration and makefile conventions in GNU Coding Standards).
In a nutshell, packages using it are configured, built, and installed with
the usual ./configure && make && make check && make install command
sequence. In practice, a few additional steps are often needed. All these
steps are split up in separate phases. See Fases de construcción, for more
info on build phases and ways to customize them.
Además, este sistema de construcción asegura que el entorno “estándar”
para paquetes GNU está disponible. Esto incluye herramientas como GCC, libc,
Coreutils, Bash, Make, Diffutils, grep y sed (vea el módulo (guix
build system gnu) para una lista completa). A estas las llamamos las
entradas implícitas de un paquete, porque las definiciones de paquete
no las mencionan.
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:
#:phasesThis argument specifies build-side code that evaluates to an alist of build phases. See Fases de construcción, for more information.
#:configure-flagsThis is a list of flags (strings) passed to the configure script.
See Definición de paquetes, for an example.
#:make-flagsThis 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-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 Sustituciones).
#:allowed-references#:disallowed-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 Invocación de guix size).
Most other build systems support these keyword arguments.
Hay definidos otros objetos <build-system> para implementar otras
convenciones y herramientas usadas por paquetes de software libre. Heredan
la mayor parte de gnu-build-system, y se diferencian principalmente en
el conjunto de entradas implícitamente añadidas al proceso de construcción,
y en la lista de fases ejecutadas. Algunos de estos sistemas de construcción
se enumeran a continuación.
(guix build-system ant) exporta esta variable. Implementa el
procedimiento de construcción de paquetes Java que pueden construirse con
la herramienta de construcción Ant.
Añade tanto ant como el kit de desarrollo Java (JDK), que
proporciona el paquete icedtea, al conjunto de entradas. Se pueden
especificar paquetes diferentes con los parámetros #:ant y
#:jdk, respectivamente.
Cuando el paquete original no proporciona un archivo Ant apropiado, el
parámetro #:jar-name puede usarse para generar un archivo de
construcción Ant build.xml mínimo con tareas para construir el
archivo jar especificado. En este caso, el parámetro #:source-dir se
puede usar para especificar el subdirectorio de fuentes, con “src” como
valor predeterminado.
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.
El parámetro #:build-target se puede usar para especificar la tarea
Ant que debe ser ejecutada durante la fase build. Por defecto se
ejecuta la tarea “jar”.
Esta variable es exportada por (guix build-system
android-ndk). Implementa un procedimiento de construcción para paquetes
Android NDK (kit de desarrollo nativo) usando un proceso de construcción
específico de Guix.
El sistema de construcción asume que los paquetes instalan sus archivos de
interfaz pública (cabeceras) en el subdirectorio include de la salida
out y sus bibliotecas en el subdirectorio lib de la salida
out".
También se asume que la unión de todas las dependencias de un paquete no tiene archivos en conflicto.
En este momento no funciona la compilación cruzada - por lo que las bibliotecas y los archivos de cabecera se asumen que son locales.
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.
El sistema de construcción usa convenciones de nombres. Para paquetes
binarios, el paquete debería estar prefijado con la implementación lisp,
como sbcl- para asdf-build-system/sbcl.
Adicionalmente, el paquete de fuentes correspondiente debe etiquetarse
usando la misma convención que los paquetes python (vea Módulos Python), usando el prefijo 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.
Esta variable se exporta en (guix build-system cargo). Permite la
construcción de paquetes usando Cargo, la herramienta de construcción del
lenguaje de programación Rust.
Automáticamente añade rustc y cargo al conjunto de
entradas. Se puede especificar el uso de un paquete Rust distinto con el
parámetro #: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.
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.
This build system adds chicken to the package inputs, as well as the
packages of 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.
Esta variable se exporta en (guix build-system copy). Permite la
construcción de paquetes simples que no necesitan mucha compilación y en su
mayor parte dependen únicamente de la copia de archivos en distintas rutas.
Añade gran parte de los paquetes de gnu-build-system al conjunto de
entradas. Por esta razón, copy-build-system no necesita toda la
verborrea que habitualmente requiere trivial-build-system.
Para simplificar más aún el proceso de instalación de archivos, se expone un
parámetro #:install-plan para permitir a quien genera el paquete
especificar dónde van los distintos archivos. El plan de instalación
(#:install-plan) es una lista de (fuente destino
[filtro]). Los filtros son opcionales.
#:include, #:include-regexp, #:exclude,
#:exclude-regexp, únicamente se seleccionan los archivos instalados
dependiendo de los filtros. Cada filtro se especifica como una lista de
cadenas.
#:include, se instalan todos los archivos de la ruta cuyo sufijo
corresponda con al menos uno de los elementos de la lista proporcionada.
#:include-regexp se instalan todos los archivos cuyas
rutas relativas correspondan con al menos una de las expresiones regulares
en la lista proporcionada.
#:exclude y #:exclude-regexp
son complementarios a sus equivalentes inclusivos. Sin opciones
#:include, se instalan todos los archivos excepto aquellos que
correspondan con los filtros de exclusión. Si se proporcionan tanto
inclusiones como exclusiones, las exclusiones tienen efecto sobre los
resultados de las inclusiones.
En todos los casos, las rutas relativas a fuente se preservan dentro de destino.
Ejemplos:
("foo/bar" "share/my-app/"): Instala bar en share/my-app/bar.
("foo/bar" "share/my-app/baz"): Instala bar en share/my-app/baz.
("foo/" "share/my-app"): Instala el contenido de foo dentro de share/my-app,
por ejemplo, instala foo/sub/file en share/my-app/sub/file.
("foo/" "share/my-app" #:include ("sub/file")): Instala únicamente foo/sub/file en
share/my-app/sub/file.
("foo/sub" "share/my-app" #:include ("file")): Instala foo/sub/file en
share/my-app/file.
Esta variable se exporta en (guix build-system clojure). Implementa
un procedimiento de construcción simple para paquetes
Clojure usando directamente compile en
Clojure. La compilación cruzada no está disponible todavía.
Añade clojure, icedtea y zip al conjunto de
entradas. Se pueden especificar paquetes diferentes con los parámetros
#:clojure, #:jdk y #:zip, respectivamente.
Una lista de directorios de fuentes, directorios de pruebas y nombres de jar
pueden especificarse con los parámetros #:source-dirs,
#:test-dirs y #:jar-names, respectivamente. El directorio de
compilación y la clase principal pueden especificarse con los parámetros
#:compile-dir y #:main-class, respectivamente. Otros
parámetros se documentan más adelante.
Este sistema de construcción es una extensión de ant-build-system, pero con las siguientes fases cambiadas:
buildEsta fase llama compile en Clojure para compilar los archivos de
fuentes y ejecuta jar para crear archivadores jar tanto de
archivos de fuentes y compilados de acuerdo con las listas de inclusión y
exclusión especificadas en #:aot-include y #:aot-exclude,
respectivamente. La lista de exclusión tiene prioridad sobre la de
inclusión. Estas listas consisten en símbolos que representan bibliotecas
Clojure o la palabra clave especial #:all que representa todas las
bibliotecas encontradas en los directorios de fuentes. El parámetro
#:omit-source? determina si las fuentes deben incluirse en los
archivadores jar.
checkEsta fase ejecuta las pruebas de acuerdo a las listas de inclusión y
exclusión especificadas en #:test-include y #:test-exclude,
respectivamente. Sus significados son análogos a los de #:aot-include
y #:aot-exclude, excepto que la palabra clave especial #:all
designa ahora a todas las bibliotecas Clojure encontradas en los directorios
de pruebas. El parámetro #:tests? determina si se deben ejecutar las
pruebas.
installEsta fase instala todos los archivadores jar construidos previamente.
Además de las previas, este sistema de construcción contiene una fase adicional:
install-docEsta fase instala todos los archivos de nivel superior con un nombre que
corresponda con %doc-regex. Una expresión regular diferente se puede
especificar con el parámetro #:doc-regex. Todos los archivos dentro
(recursivamente) de los directorios de documentación especificados en
#:doc-dirs se instalan también.
Esta variable se exporta en (guix build-system cmake). Implementa el
procedimiento de construcción para paquetes que usen la
herramienta de construcción CMake.
Automáticamente añade el paquete cmake al conjunto de entradas. El
paquete usado se puede especificar con el parámetro #:cmake.
El parámetro #:configure-flags se toma como una lista de opciones a
pasar a cmake. El parámetro #:build-type especifica en
términos abstractos las opciones pasadas al compilador; su valor
predeterminado es "RelWithDebInfo" (quiere decir “modo de entrega
con información de depuración”), lo que aproximadamente significa que el
código se compila con -O2 -g, lo cual es el caso predeterminado en
paquetes basados en Autoconf.
Esta variable se exporta en (guix build-system dune). Permite la
construcción de paquetes mediante el uso de Dune, una herramienta de construcción para el lenguaje de programación
OCaml. Se implementa como una extensión de ocaml-build-system que se
describe a continuación. Como tal, se pueden proporcionar los parámetros
#:ocaml y #:findlib a este sistema de construcción.
Automáticamente añade el paquete dune al conjunto de entradas. El
paquete usado se puede especificar con el parámetro #:dune.
No existe una fase configure debido a que los paquetes dune no
necesitan ser configurados típicamente. El parámetro #:build-flags se
toma como una lista de opciones proporcionadas a la orden dune
durante la construcción.
El parámetro #:jbuild? puede proporcionarse para usar la orden
jbuild en vez de la más reciente dune durante la construcción
de un paquete. Su valor predeterminado es #f.
El parámetro #:package puede proporcionarse para especificar un
nombre de paquete, lo que resulta útil cuando un paquete contiene múltiples
paquetes y únicamente quiere construir uno de ellos. Es equivalente a
proporcionar el parámetro -p a 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 Paquetes 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 Definición de variantes de paquetes) 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.
Esta variable se exporta en (guix build-system go). Implementa el
procedimiento de construcción para paquetes Go usando los
mecanismos de construcción de Go estándares.
Se espera que la usuaria proporcione un valor para el parámetro
#:import-path y, en algunos caso, #:unpack-path. La
ruta de importación
corresponde a la ruta del sistema de archivos esperada por los guiones de
construcción del paquete y los paquetes a los que hace referencia, y
proporciona una forma de hacer referencia a un paquete Go unívocamente. Está
basado típicamente en una combinación de la URI remota del paquete de
archivos de fuente y la estructura jerárquica del sistema de archivos. En
algunos casos, necesitará desempaquetar el código fuente del paquete en una
estructura de directorios diferente a la indicada en la ruta de importación,
y #:unpack-path debe usarse en dichos casos.
Los paquetes que proporcionan bibliotecas Go deben instalar su código fuente
en la salida de la construcción. El parámetro #:install-source?, cuyo
valor por defecto es #t, controla si se instalará o no el código
fuente. Puede proporcionarse #f en paquetes que proporcionan
únicamente archivos ejecutables.
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.
Esta variable se exporta en (guix build-system glib-or-gtk). Está
pensada para usarse con paquetes que usan GLib o GTK+.
Este sistema de construcción añade las dos fases siguientes a las definidas en gnu-build-system:
glib-or-gtk-wrapLa fase glib-or-gtk-wrap se asegura de que los programas en
bin/ son capaces de encontrar los “esquemas” GLib y los
módulos
GTK+. Esto se consigue recubriendo los programas en guiones de lanzamiento
que proporcionan valores apropiados para las variables de entorno
XDG_DATA_DIRS y GTK_PATH.
Es posible excluir salidas específicas del paquete del proceso de
recubrimiento enumerando sus nombres en el parámetro
#:glib-org-gtk-wrap-excluded-outputs. Esto es útil cuando se sabe que
una salida no contiene binarios GLib o GTK+, y cuando empaquetar
gratuitamente añadiría una dependencia de dicha salida en GLib y GTK+.
glib-or-gtk-compile-schemasLa fase glib-or-gtk-compile-schemas se asegura que todos los
esquemas GSettings o GLib se compilan. La compilación la realiza el
programa glib-compile-schemas. Lo proporciona el paquete
glib:bin que se importa automáticamente por el sistema de
construcción. El paquete glib que proporciona
glib-compile-schemas puede especificarse con el parámetro
#:glib.
Ambas fases se ejecutan tras la fase install.
Este sistema de construcción es para paquetes Guile que consisten
exclusivamente en código Scheme y son tan simples que no tienen ni siquiera
un archivo Makefile, menos un guión configure. Compila código Scheme
usando guild compile (see Compilation in GNU Guile
Reference Manual) e instala los archivos .scm y .go en el
lugar correcto. También instala documentación.
Este sistema de construcción permite la compilación cruzada usando la opción
--target de guild compile.
Los paquetes construidos con guile-build-system deben proporcionar un
paquete Guile en su campo native-inputs.
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 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 Fases de construcción) 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 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.
Esta variable se exporta en (guix build-system maven). Implementa un
procedimiento de construcción para paquetes basados en
Maven. Maven es una herramienta para Java
de gestión de dependencias y ciclo de vida. Las usuarias de Maven
especifican las dependencias y módulos en un archivo pom.xml que
Maven lee. Cuando Maven no dispone de una de dichas dependencias o módulos
en su repositorio, las descarga y las usa para construir el paquete.
El sistema de compilación de maven se asegura de que maven no intentará descargar ninguna dependencia ejecutándo maven en modo sin conexión. Maven fallará si falta alguna dependencia. Antes de ejecutar Maven, el archivo pom.xml (y los subproyectos) se modifican para especificar la versión de las dependencias y módulos que corresponden a las versiones disponibles en el entorno de construcción de guix. Las dependencias y los módulos se deben instalar en un repositorio de maven ad hoc en lib/m2, y se enlazan un repositorio real antes de que se ejecute maven. Se le indica a Maven que use ese repositorio para la construcción e instale los artefactos generados allí. Los archivos cambiados se copian del directorio lib/m2 a la salida del paquete.
Puede especificar un archivo pom.xml con el parámetro
#:pom-file, o dejar al sistema de construcción usar el archivo
predeterminado pom.xml en las fuentes.
En caso de que necesite especificar la versión de una dependencia
manualmente puede usar el parámetro #:local-packages. Toma como valor
una lista asociativa donde la clave es el valor del campo “groupId” del
paquete y su valor es una lista asociativa donde la clave es el campo
“artifactId” del paquete y su valor la versión que quiere forzar en vez de
la que se encuentra en pom.xml.
Algunos paquetes usan dependencias o módulos que no son útiles en tiempo de
ejecución ni en tiempo de construcción en Guix. Puede modificar el archivo
pom.xml para eliminarlos usando el parámetro #:exclude. Su
valor es una lista asociativa donde la clave es el valor del campo
“groupId” del módulo o dependencia que quiere eliminar, y su valor es una
lista de valores del campo “artifactId” que se eliminarán.
Puede usar valores distintos para los paquetes jdk y maven con
el parámetro correspondiente, #:jdk y #:maven.
El parámetro #:maven-plugins es una lista de módulos de maven usados
durante la construcción, con el mismo formato que el campo inputs de
la declaración del paquete. Su valor predeterminado es
(default-maven-plugins) que también se exporta.
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.
Esta variable se exporta en (guix build-system minify). Implementa un
procedimiento de minificación para paquetes JavaScript simples.
Añade uglify-js al conjunto de entradas y lo utiliza para comprimir
todos los archivos JavaScript en el directorio src. Un paquete de
minificación diferente puede especificarse con el parámetro
#:uglify-js, pero se espera que el paquete escriba el código
minificado en la salida estándar.
Cuando los archivos JavaScript de entrada no se encuentran en el directorio
src, el parámetro #:javascript-files puede usarse para
especificar una lista de nombres de archivo que proporcionar al minificador.
Esta variable se exporta en (guix build-system ocaml). Implementa un
procedimiento de construcción para paquetes OCaml,
que consiste en seleccionar el conjunto correcto de órdenes a ejecutar para
cada paquete. Los paquetes OCaml pueden esperar la ejecución de muchas
ordenes diferentes. Este sistema de construcción probará algunas de ellas.
Cuando el paquete tiene un archivo setup.ml presente en el nivel
superior, se ejecuta ocaml setup.ml -configure, ocaml setup.ml
-build y ocaml setup.ml -install. El sistema de construcción asumirá
que este archivo se generó con http://oasis.forge.ocamlcore.org/
OASIS y se encargará de establecer el prefijo y la activación de las
pruebas si no se desactivaron. Puede pasar opciones de configuración y
construcción con #:configure-flags y #:build-flags,
respectivamente. El parámetro #:test-flags puede usarse para cambiar
el conjunto de opciones usadas para activar las pruebas. El parámetro
#:use-make? puede usarse para ignorar este sistema en las fases de
construcción e instalación.
Cuando el paquete tiene un archivo configure, se asume que es un
guión de configuración hecho a mano que necesita un formato de parámetros
diferente a los del sistema gnu-build-system. Puede añadir más
opciones con el parámetro #:configure-flags.
Cuando el paquete tiene un archivo Makefile (o #:use-make? es
#t), será usado y se pueden proporcionar más opciones para las fases
de construcción y e instalación con el parámetro #:make-flags.
Por último, algunos paquetes no tienen estos archivos y usan unas
localizaciones de algún modo estándares para su sistema de construcción. En
este caso, el sistema de construcción ejecutará ocaml pkg/pkg.ml o
ocaml pkg/build.ml y se hará cargo de proporcionar la ruta del módulo
findlib necesario. Se pueden pasar opciones adicionales con el parámetro
#:build-flags. De la instalación se hace cargo
opam-installer. En este caso, el paquete opam debe añadirse
al campo native-inputs de la definición del paquete.
Fíjese que la mayoría de los paquetes OCaml asumen su instalación en el
mismo directorio que OCaml, lo que no es el comportamiento deseado en
guix. En particular, tratarán de instalar archivos .so en su
directorio de módulos, lo que normalmente es aceptable puesto que está bajo
el directorio del compilador de OCaml. No obstante, en guix estas
bibliotecas no se pueden instalar ahí, por lo que se usa
CAML_LD_LIBRARY_PATH. Esta variable apunta a
lib/ocaml/site-lib/stubslibs y allí es donde se deben instalar las
bibliotecas .so.
Esta variable se exporta en (guix build-system python). Implementa el
procedimiento más o menos estándar de construcción usado por paquetes
Python, que consiste en la ejecución de python setup.py build y
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.
Se puede especificar el paquete Python usado para llevar a cabo la
construcción con el parámetro #:python. Esta es habitualmente una
forma de forzar la construcción de un paquete para una versión específica
del intérprete Python, lo que puede ser necesario si el paquete es
compatible únicamente con una versión del intérprete.
De manera predeterminada guix llama a setup.py bajo el control de
setuptools de manera similar a lo realizado por
pip. Algunos paquetes no son compatibles con setuptools (y pip),
por lo que puede desactivar esta configuración estableciendo el parámetro
#:use-setuptools a #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.
#: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.
Esta variable se exporta en (guix build-system perl). Implementa el
procedimiento de construcción estándar para paquetes Perl, lo que o bien
consiste en la ejecución de perl Build.PL
--prefix=/gnu/store/…, seguido de Build y Build
install; o en la ejecución de perl Makefile.PL
PREFIX=/gnu/store/…, seguida de make y make install,
dependiendo de si Build.PL o Makefile.PL están presentes en la
distribución del paquete. El primero tiene preferencia si existen tanto
Build.PL como Makefile.PL en la distribución del paquete. Esta
preferencia puede ser invertida mediante la especificación del valor
#t en el parámetro #:make-maker?.
La invocación inicial de perl Makefile.PL o perl Build.PL pasa
a su vez las opciones especificadas por los parámetros
#:make-maker-flags o #:module-build-flags, respectivamente.
El paquete Perl usado puede especificarse con #:perl.
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.
Esta variable se exporta en (guix build-system qt). Está pensado para
usarse con aplicaciones que usen Qt o KDE.
Este sistema de construcción añade las dos fases siguientes a las definidas en cmake-build-system:
check-setupLa fase check-setup prepara el entorno para la ejecución de las
comprobaciones usadas habitualmente por los programas de pruebas de Qt. Por
ahora únicamente proporciona valor a algunas variables de entorno:
QT_QPA_PLATFORM=offscreen, DBUS_FATAL_WARNINGS=0 y
CTEST_OUTPUT_ON_FAILURE=1.
Esta fase se añade previamente a la fase check. Es una fase separada
para facilitar el ajuste si fuese necesario.
qt-wrapLa fase qt-wrap busca las rutas de módulos de Qt5, las rutas de QML y
algunas rutas XDG en las entradas y la salida. En caso de que alguna ruta se
encuentra, todos los programas en los directorios bin/, sbin/,
libexec/ y lib/libexec/ de la salida se envuelven en guiones
que definen las variables de entorno necesarias.
Es posible excluir salidas específicas del paquete del proceso de
recubrimiento enumerando sus nombres en el parámetro
#:qt-wrap-excluded-outputs. Esto es útil cuando se sabe que una
salida no contiene binarios que usen Qt, y cuando empaquetar gratuitamente
añadiría una dependencia de dicha salida en Qt.
Ambas fases se añaden tras la fase install.
Esta variable se exporta en (guix build-system r). Implementa el
procedimiento de construcción usados por paquetes
R, lo que esencialmente es poco más que la
ejecución de ‘R CMD INSTALL --library=/gnu/store/…’ en un entorno
donde R_LIBS_SITE contiene las rutas de todos los paquetes R de
entrada. Las pruebas se ejecutan tras la instalación usando la función R
tools::testInstalledPackage.
This variable is exported by (guix build-system rakudo). It
implements the build procedure used by Rakudo
for Perl6 packages. It installs the package to
/gnu/store/…/NAME-VERSION/share/perl6 and installs the
binaries, library files and the resources, as well as wrap the files under
the bin/ directory. Tests can be skipped by passing #f to the
tests? parameter.
El paquete rakudo en uso puede especificarse con rakudo. El paquete
perl6-tap-harness en uso durante las pruebas puede especificarse con
#:prove6 o eliminarse proporcionando #f al parámetro
with-prove6?. El paquete perl6-zef en uso durante las pruebas e
instalación puede especificarse con #:zef o eliminarse proporcionando
#f al parámetro 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.
Esta variable se exporta en (guix build-system texlive). Se usa para
construir paquetes TeX en modo de procesamiento de lotes con el motor
especificado. El sistema de construcción proporciona valor a la variable
TEXINPUTS para encontrar todos los archivos de fuentes TeX en las
entradas.
Por defecto ejecuta luatex en todos los archivos que terminan en
ins. Un motor y formato diferente puede especificarse con el
parámetro #:tex-format. Los diferentes objetivos de construcción
pueden especificarse con el parámetro #:build-targets, que espera una
lista de nombres de archivo. El sistema de construcción añade únicamente
texlive-bin y texlive-latex-base (ambos desde (gnu
packages tex) a las entradas. Ambos pueden forzarse con los parámetros
#:texlive-bin y #:texlive-latex-base respectivamente.
El parámetro #:tex-directory le dice al sistema de construcción dónde
instalar los archivos construidos bajo el árbol texmf.
Esta variable se exporta en (guix build-system ruby). Implementa el
procedimiento de construcción de RubyGems usado por los paquetes Ruby, que
implica la ejecución de gem build seguida de gem install.
El campo source de un paquete que usa este sistema de construcción
típicamente se refiere a un archivo gem, ya que este es el formato usado por
las desarrolladoras Ruby cuando publican su software. El sistema de
construcción desempaqueta el archivo gem, potencialmente parchea las
fuentes, ejecuta la batería de pruebas, vuelve a empaquetar el archivo gem y
lo instala. Adicionalmente, se puede hacer referencia a directorios y
archivadores tar para permitir la construcción de archivos gem no publicados
desde Git o un archivador tar de publicación de fuentes tradicional.
Se puede especificar el paquete Ruby usado mediante el parámetro
#:ruby. Una lista de opciones adicionales pueden pasarse a la orden
gem en el parámetro #:gem-flags.
Esta variable se exporta en (guix build-system waf). Implementa un
procedimiento de construcción alrededor del guión waf. Las fases
comunes—configure, build y install—se implementan
pasando sus nombres como parámetros al guión waf.
El guión waf es ejecutado por el intérprete Python. El paquete Python
usado para la ejecución puede ser especificado con el parámetro
#:python.
Esta variable se exporta en (guix build-system scons). Implementa en
procedimiento de construcción usado por la herramienta de construcción de
software SCons. Este sistema de construcción ejecuta scons para
construir el paquete, scons test para ejecutar las pruebas y después
scons install para instalar el paquete.
Las opciones adicionales a pasar a scons se pueden especificar con el
parámetro #:scons-flags. Los objetivos predeterminados de
construcción (build) e instalación (install) pueden modificarse con
#:build-targets y #:install-targets respectivamente. La
versión de Python usada para ejecutar SCons puede especificarse
seleccionando el paquete SCons apropiado con el parámetro #:scons.
Esta variable se exporta en (guix build-system haskell). Implementa
el procedimiento de construcción Cabal usado por paquetes Haskell, el cual
implica la ejecución de runhaskell Setup.hs configure
--prefix=/gnu/store/… y runhaskell Setup.hs build. En vez de
instalar el paquete ejecutando runhaskell Setup.hs install, para
evitar el intento de registro de bibliotecas en el directorio de
solo-lectura del compilador en el almacén, el sistema de construcción usa
runhaskell Setup.hs copy, seguido de runhaskell Setup.hs
register. Además, el sistema de construcción genera la documentación del
paquete ejecutando runhaskell Setup.hs haddock, a menos que se pasase
#:haddock? #f. Parámetros opcionales de Haddock pueden proporcionarse
con la ayuda del parámetro #:haddock-flags. Si el archivo
Setup.hs no es encontrado, el sistema de construcción busca
Setup.lhs a su vez.
El compilador Haskell usado puede especificarse con el parámetro
#:haskell cuyo valor predeterminado es ghc.
Esta variable se exporta en (guix build-system dub). Implementa el
procedimiento de construcción Dub usado por los paquetes D, que implica la
ejecución de dub build y dub run. La instalación se lleva a
cabo con la copia manual de los archivos.
El compilador D usado puede ser especificado con el parámetro #:ldc
cuyo valor predeterminado es ldc.
Esta variable se exporta en (guix build-system emacs). Implementa un
procedimiento de instalación similar al propio sistema de empaquetado de
Emacs (see Packages in The GNU Emacs Manual).
Primero crea el archivo paquete-autoloads.el, tras lo que
compila todos los archivos Emacs Lisp. De manera diferente al sistema de
paquetes de Emacs, los archivos de documentación Info se mueven al
directorio estándar de documentación y se borra el archivo dir. Los
archivos del paquete Elisp se instalan directamente en
share/emacs/site-lisp.
Esta variable se exporta en (guix build-system font). Implementa un
procedimiento de instalación para paquetes de fuentes donde las proveedoras
originales proporcionan archivos de tipografía TrueType, OpenType, etc.
precompilados que simplemente necesitan copiarse en su lugar. Copia los
archivos de tipografías a las localizaciones estándar en el directorio de
salida.
Esta variable se exporta en (guix build-system meson). Implementa el
procedimiento de construcción para paquetes que usan
Meson como su sistema de construcción.
It adds both Meson and Ninja to the set of
inputs, and they can be changed with the parameters #:meson and
#:ninja if needed.
Este sistema de construcción es una extensión de gnu-build-system, pero con las siguientes fases cambiadas por otras específicas para Meson:
configureEsta fase ejecuta meson con las opciones especificadas en
#:configure-flags. La opción --buildtype recibe el valor
debugoptimized excepto cuando se especifique algo distinto en
#:build-type.
buildEsta fase ejecuta ninja para construir el paquete en paralelo por
defecto, pero esto puede cambiarse con #: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.
installEsta fase ejecuta ninja install y no puede cambiarse.
Aparte de estas, el sistema de ejecución también añade las siguientes fases:
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-wrapEsta fase es la fase proporcionada por glib-or-gtk-build-system, y no
está activa por defecto. Puede activarse con #:glib-or-gtk.
glib-or-gtk-compile-schemasEsta fase es la fase proporcionada por glib-or-gtk-build-system, y no
está activa por defecto. Puede activarse con #:glib-or-gtk.
linux-module-build-system permite la construcción de módulos del núcleo Linux.
Este sistema de construcción es una extensión de gnu-build-system, pero con las siguientes fases cambiadas:
configureEsta fase configura el entorno de modo que el Makefile del núcleo Linux pueda usarse para la construcción del módulo externo del núcleo.
buildEsta fase usa el Makefile del núcleo Linux para construir el módulo externo del núcleo.
installEsta fase usa el Makefile del núcleo Linux para instalar el módulo externo del núcleo.
Es posible y útil especificar el núcleo Linux usado para la construcción del
módulo (para ello debe usar el parámetro #:linux a través de la forma
arguments en un paquete que use linux-module-build-system).
Esta variable se exporta en (guix build-system node). Implementa el
procedimiento de construcción usado por Node.js,
que implementa una aproximación de la orden npm install, seguida de
una orden npm test.
El paquete Node.js usado para interpretar las órdenes npm puede
especificarse a través del parámetro #:node cuyo valor predeterminado
es node.
Por último, para paquetes que no necesiten nada tan sofisticado se proporciona un sistema de construcción “trivial”. Es trivial en el sentido de que no proporciona prácticamente funcionalidad: no incorpora entradas implícitas y no tiene una noción de fases de construcción.
Esta variable se exporta en (guix build-system trivial).
Este sistema de construcción necesita un parámetro #:builder. Este
parámetro debe ser una expresión Scheme que construya la(s) salida(s) del
paquete—como en 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 Canales); 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).
The resulting package is a Guix instance of the given channel, similar to
how guix time-machine would build it.
Next: Fases de construcción, Previous: Writing Manifests, Up: Interfaz programática [Contents][Index]