Sistemas de construcción (Manual de referencia de GNU Guix)

8.5 Sistemas de construcción

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

Variable: gnu-build-system

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:

#:phases

This argument specifies build-side code that evaluates to an alist of build phases. See Fases de construcción, for more information.

#:configure-flags

This is a list of flags (strings) passed to the configure script. See Definición de paquetes, 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. 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-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 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.

Variable: agda-build-system

This variable is exported by (guix build-system agda). It implements a build procedure for Agda libraries.

It adds agda to the set of inputs. A different Agda can be specified with the #:agda key.

The #:plan key is a list of cons cells (regexp . parameters), where regexp is a regexp that should match the .agda files to build, and parameters is an optional list of parameters that will be passed to agda when type-checking it.

When the library uses Haskell to generate a file containing all imports, the convenience #:gnu-and-haskell? can be set to #t to add ghc and the standard inputs of gnu-build-system to the input list. You will still need to manually add a phase or tweak the 'build phase, as in the definition of agda-stdlib.

Variable: ant-build-system

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

Variable: android-ndk-build-system

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.

Variable: asdf-build-system/source

Variable: asdf-build-system/sbcl

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.

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

Variable: cargo-build-system

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.

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.

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.

Variable: copy-build-system

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.

Cuando fuente corresponde con un archivo o un directorio sin la barra final, se instala en destino.
- Si destino contiene una barra al final, fuente se instala con su nombre de archivo en la ruta destino.
- En otro caso se instala fuente como destino.
Cuando fuente es un directorio terminado en una barra, o cuando se usa algún filtro, la barra al final de destino tiene el significado que se describió anteriormente.
- Sin filtros, instala todo el contenido de fuente en destino.
- Cuando filtro contiene #: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.
  - Con #:include, se instalan todos los archivos de la ruta cuyo sufijo corresponda con al menos uno de los elementos de la lista proporcionada.
  - Con #:include-regexp se instalan todos los archivos cuyas rutas relativas correspondan con al menos una de las expresiones regulares en la lista proporcionada.
  - Los filtros #: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.
- When a package has multiple outputs, the #:output argument can be used to specify which output label the files should be installed to.
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.
("foo/doc" "share/my-app/doc" #:output "doc"): Install "foo/doc" to "share/my-app/doc" within the "doc" output.

Variable: vim-build-system

This variable is exported by (guix build-system vim). It is an extension of the copy-build-system, installing Vim and Neovim plugins into locations where these two text editors know to find their plugins, using their packpaths.

Packages which are prefixed with vim- will be installed in Vim’s packpath, while those prefixed with neovim- will be installed in Neovim’s packpath. If there is a doc directory with the plugin then helptags will be generated automatically.

There are a couple of keywords added with the vim-build-system:

With plugin-name it is possible to set the name of the plugin. While by default this is set to the name and version of the package, it is often more helpful to set this to name which the upstream author calls their plugin. This is the name used for :packadd from inside Vim.
With install-plan it is possible to augment the built-in install-plan of the vim-build-system. This is particularly helpful if you have files which should be installed in other locations. For more information about using the install-plan, see the copy-build-system (see copy-build-system).
With #:vim it is possible to add this package to Vim’s packpath, in addition to if it is added automatically because of the vim- prefix in the package’s name.
With #:neovim it is possible to add this package to Neovim’s packpath, in addition to if it is added automatically because of the neovim- prefix in the package’s name.
With #:mode it is possible to adjust the path which the plugin is installed into. By default the plugin is installed into start and other options are available, including opt. Adding a plugin into opt will mean you will need to run, for example, :packadd foo to load the foo plugin from inside of Vim.

Variable: clojure-build-system

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:

build: Esta 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.
check: Esta 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.
install: Esta fase instala todos los archivadores jar construidos previamente.

Además de las previas, este sistema de construcción contiene una fase adicional:

install-doc: Esta 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.

Variable: cmake-build-system

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.

Variable: composer-build-system

This variable is exported by (guix build-system composer). It implements the build procedure for packages using Composer, the PHP package manager.

It automatically adds the php package to the set of inputs. Which package is used can be specified with the #:php parameter.

The #:test-target parameter is used to control which script is run for the tests. By default, the test script is run if it exists. If the script does not exist, the build system will run phpunit from the source directory, assuming there is a phpunit.xml file.

Variable: dune-build-system

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.

Variable: elm-build-system

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:

The build system is focused on packages in the Elm sense of the word: Elm projects which declare { "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 supports multiple versions of a package coexisting simultaneously under 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.
We are not yet able to run tests for Elm projects because neither elm-test-rs nor the Node.js-based elm-test runner has been packaged for Guix yet.

Variable: go-build-system

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.

The key #:go can be used to specify the Go compiler package with which to build the package.

The phase check provides a wrapper for go test which builds a test binary (or multiple binaries), vets the code and then runs the test binary. Build, test and test binary flags can be provided as #:test-flags parameter, default is '(). See go help test and go help testflag for more details.

The key #:embed-files, default is '(), provides a list of future embedded files or regexps matching files. They will be copied to build directory after unpack phase. See https://pkg.go.dev/embed for more details.

Variable: glib-or-gtk-build-system

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-wrap

La 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-schemas

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

Variable: guile-build-system

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.

Variable: 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 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") "\")\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.

Variable: maven-build-system

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.

Variable: minetest-mod-build-system: 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.

Variable: minify-build-system

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.

Variable: mozilla-build-system: This variable is exported by (guix build-system mozilla). It sets the --target and --host configuration flags to what software developed by Mozilla expects – due to historical reasons, Mozilla software expects --host to be the system that is cross-compiled from and --target to be the system that is cross-compiled to, contrary to the standard Autotools conventions.

Variable: ocaml-build-system

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.

Variable: python-build-system

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.

Variable: pyproject-build-system

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.

Variable: perl-build-system

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.

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.

Variable: qt-build-system

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-setup

La 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-wrap

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

Variable: r-build-system: 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.

Variable: rakudo-build-system

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

Variable: rebar-build-system

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:

unpack: This 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.
bootstrap
configure: There are no bootstrap and configure phase because erlang packages typically don’t need to be configured.
build: This phase runs rebar3 compile with the flags listed in #:rebar-flags.
check: Unless #:tests? #f is passed, this phase runs rebar3 eunit, or some other target specified with #:test-target, with the flags listed in #:rebar-flags,
install: This installs the files created in the default profile, or some other profile specified with #:install-profile.

Variable: texlive-build-system

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.

By default it tries to run luatex on all .ins files, and if it fails to find any, on all .dtx files. A different engine and format can be specified with, respectively, the #:tex-engine and #:tex-format arguments. Different build targets can be specified with the #:build-targets argument, which expects a list of file names.

It also generates font metrics (i.e., .tfm files) out of Metafont files whenever possible. Likewise, it can also create TeX formats (i.e., .fmt files) listed in the #:create-formats argument, and generate a symbolic link from bin/ directory to any script located in texmf-dist/scripts/, provided its file name is listed in #:link-scripts argument.

The build system adds texlive-bin from (gnu packages tex) to the native inputs. It can be overridden with the #:texlive-bin argument.

The package texlive-latex-bin, from the same module, contains most of the tools for building TeX Live packages; for convenience, it is also added by default to the native inputs. However, this can be troublesome when building a dependency of texlive-latex-bin itself. In this particular situation, the #:texlive-latex-bin? argument should be set to #f.

Variable: ruby-build-system

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.

Variable: waf-build-system

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.

Variable: zig-build-system

This variable is exported by (guix build-system zig). It implements the build procedures for the Zig build system (zig build command).

Selecting this build system adds zig to the package inputs, in addition to the packages of gnu-build-system.

There is no configure phase because Zig packages typically do not need to be configured. The #:zig-build-flags parameter is a list of flags that are passed to the zig command during the build. The #:zig-test-flags parameter is a list of flags that are passed to the zig test command during the check phase. The default compiler package can be overridden with the #:zig argument.

The optional zig-release-type parameter declares the type of release. Possible values are: safe, fast, or small. The default value is #f, which causes the release flag to be omitted from the zig command. That results in a debug build.

Variable: scons-build-system

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.

Variable: haskell-build-system

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.

Variable: dub-build-system

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.

Variable: emacs-build-system

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.

Variable: font-build-system: 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.

Variable: meson-build-system

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:

configure: Esta 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.
build: Esta fase ejecuta ninja para construir el paquete en paralelo por defecto, pero esto puede cambiarse con #:parallel-build?.
check: The phase runs ‘meson test’ with a base set of options that cannot be overridden. This base set of options can be extended via the #:test-options argument, for example to select or skip a specific test suite.
install: Esta fase ejecuta ninja install y no puede cambiarse.

Aparte de estas, el sistema de ejecución también añade las siguientes fases:

fix-runpath: This phase ensures that all binaries can find the libraries they need. It searches for required libraries in subdirectories of the package being built, and adds those to RUNPATH where needed. It also removes references to libraries left over from the build phase by meson, such as test dependencies, that aren’t actually required for the program to run.
glib-or-gtk-wrap: Esta 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-schemas: Esta fase es la fase proporcionada por glib-or-gtk-build-system, y no está activa por defecto. Puede activarse con #:glib-or-gtk.

Variable: linux-module-build-system

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:

configure: Esta 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.
build: Esta fase usa el Makefile del núcleo Linux para construir el módulo externo del núcleo.
install: Esta 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).

Variable: node-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.

Variable: tree-sitter-build-system

This variable is exported by (guix build-system tree-sitter). It implements procedures to compile grammars for the Tree-sitter parsing library. It essentially runs tree-sitter generate to translate grammar.js grammars to JSON and then to C. Which it then compiles to native code.

Tree-sitter packages may support multiple grammars, so this build system supports a #:grammar-directories keyword to specify a list of locations where a grammar.js file may be found.

Grammars sometimes depend on each other, such as C++ depending on C and TypeScript depending on JavaScript. You may use inputs to declare such dependencies.

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.

Variable: trivial-build-system

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

Variable: channel-build-system

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

Optionally, a #:channels argument specifying additional channels can be provided.

The resulting package is a Guix instance of the given channel(s), similar to how guix time-machine would build it.