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

8.4 Sistemas de construcción

Cada definición de paquete especifica un sistema de construcción y parámetros para dicho sistema de construcción (véase 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 (véase 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 (véase 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 (véase Definición de paquetes). Normalmente son parámetros con palabras clave (véase keyword arguments in Guile en 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 (véase 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 Scheme: gnu-build-system

gnu-build-system representa el sistema de construcción GNU y sus variantes (véase configuration and makefile conventions en 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. Véase 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. Véase Fases de construcción, for more information.

#:configure-flags

This is a list of flags (strings) passed to the configure script. Véase 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 (véase --cores).

#:validate-runpath?

This Boolean, #t by default, determines whether to “validate” the RUNPATH of ELF binaries (.so shared libraries as well as executables) previously installed by the install phase.

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

#:substitutable?

This Boolean, #t by default, tells whether the package outputs should be substitutable—i.e., whether users should be able to obtain substitutes for them instead of building locally (véase 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 (véase 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 Scheme: 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 Scheme: 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 Scheme: asdf-build-system/source

Variable Scheme: asdf-build-system/sbcl

Variable Scheme: 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 (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.

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

Scheme Variable: chicken-build-system

This variable is exported by (guix build-system chicken). It builds CHICKEN Scheme modules, also called “eggs” or “extensions”. CHICKEN generates C source code, which then gets compiled by a C compiler, in this case GCC.

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 Scheme: 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.
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.

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

Variable Scheme: 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 Scheme: 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 (véase Compilation en 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 Scheme: julia-build-system

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

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

Julia packages usually manage their binary dependencies via JLLWrappers.jl, a Julia package that creates a module (named after the wrapped library followed by _jll.jl.

To add the binary path _jll.jl packages, you need to patch the files under src/wrappers/, replacing the call to the macro JLLWrappers.@generate_wrapper_header, adding as a second argument containing the store path the binary.

As an example, in the MbedTLS Julia package, we add a build phase (véase 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 Package.toml yet, will require this file to be created, too. The function julia-create-package-toml helps creating the file. You need to pass the outputs and the source of the package, it’s name (the same as the file-name parameter), the package uuid, the package version, and a list of dependencies specified by their name and their uuid.

Variable Scheme: 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 Scheme: 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 Scheme: 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 Scheme: 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/….

Para que instalan programas independientes Python bajo bin/, se encarga de envolver dichos programas de modo que su variable de entorno PYTHONPATH apunte a las bibliotecas Python de las que dependen.

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.

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

Scheme Variable: renpy-build-system

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

It further creates a wrapper script in bin/ and a desktop entry in share/applications, both of which can be used to launch the game.

Which Ren’py package is used can be specified with #:renpy. Games can also be installed in outputs other than “out” by using #:output.

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

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.

Variable Scheme: 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 Scheme: 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 Scheme: 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 Scheme: 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 Scheme: 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 Scheme: 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 (véase Packages en 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 Scheme: 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 Scheme: 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.

Añade Meson y Ninja al conjunto de entradas, y pueden cambiarse con los parámetros #:meson y #:ninja en caso necesario. La versión de Meson predeterminada es meson-for-build, la cual es especial puesto que no limpia el RUNPATH de los binarios y bibliotecas durante la instalación.

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: Esta fase ejecuta ninja con el objetivo especificado en #:test-target, cuyo valor predeterminado es "test".
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: Esta fase se asegura de que todos los binarios pueden encontrar las bibliotecas que necesitan. Busca las bibliotecas necesarias en subdirectorios del paquete en construcción, y añade estas a RUNPATH en caso necesario. También elimina referencias a bibliotecas introducidas en la fase de construcción por meson-for-build, como las dependencias de las pruebas, que no se necesitan realmente para la ejecución del programa.
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 Scheme: 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 Scheme: 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.

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 Scheme: 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 (véase build-expression->derivation).