Siguiente: Fases de construcción, Anterior: Definición de variantes de paquetes, Subir: Interfaz programática [Índice general][Índice]
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)
.
gnu-build-system representa el sistema de construcción GNU y sus variantes (véase configuration and makefile conventions en GNU Coding Standards).
En resumen, los paquetes que lo usan se configuran, construyen e instalan
con la habitual secuencia de órdenes ./configure && make && make check
&& make install
. En la práctica, algunos pasos adicionales son necesarios
habitualmente. Todos estos pasos se dividen en fases separadas,
notablemente18:
unpack
Extrae el archivador tar de la fuente, y cambia el directorio actual al directorio recién extraído. Si la fuente es realmente un directorio, lo copia al árbol de construcción y entra en ese directorio.
patch-source-shebangs
Sustituye secuencias “#!” encontradas al inicio de los archivos de fuentes
para que hagan referencia a los nombres correctos de archivos del
almacén. Por ejemplo, esto cambia #!/bin/sh
por
#!/gnu/store/…-bash-4.3/bin/sh
.
configure
Ejecuta el guión configure con algunas opciones predeterminadas, como
--prefix=/gnu/store/…, así como las opciones especificadas
por el parámetro #:configure-flags
.
build
Ejecuta make
con la lista de opciones especificadas en
#:make-flags
. Si el parámetro #:parallel-build?
es verdadero
(por defecto), construye con make -j
.
check
Ejecuta make check
, u otro objetivo especificado con
#:test-target
, a menos que se pasase #:tests? #f
. Si el
parámetro #:parallel-tests?
es verdadero (por defecto), ejecuta
make check -j
.
install
Ejecuta make install
con las opciones enumeradas en
#:make-flags
.
patch-shebangs
Sustituye las secuencias “#!” en los archivos ejecutables instalados.
strip
Extrae los símbolos de depuración de archivos ELF (a menos que el valor de
#:strip-binaries?
sea falso), y los copia a la salida debug
cuando esté disponible (véase Instalación de archivos de depuración).
El módulo del lado de construcción (guix build gnu-build-system)
define %standard-phases como la lista predeterminada de fases de
construcción. %standard-phases es una lista de pares
símbolo/procedimiento, donde el procedimiento implementa realmente la fase.
Véase Fases de construcción para más información sobre las fases de construcción y formas de personalizarlas.
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.
Hay definidos otros objetos <build-system>
para implementar otras
convenciones y herramientas usadas por paquetes de software libre. Heredan
la mayor parte de gnu-build-system, y se diferencian principalmente en
el conjunto de entradas implícitamente añadidas al proceso de construcción,
y en la lista de fases ejecutadas. Algunos de estos sistemas de construcción
se enumeran a continuación.
(guix build-system ant)
exporta esta variable. Implementa el
procedimiento de construcción de paquetes Java que pueden construirse con
la herramienta de construcción Ant.
Añade tanto ant
como el kit de desarrollo Java (JDK), que
proporciona el paquete icedtea
, al conjunto de entradas. Se pueden
especificar paquetes diferentes con los parámetros #:ant
y
#:jdk
, respectivamente.
Cuando el paquete original no proporciona un archivo Ant apropiado, el
parámetro #:jar-name
puede usarse para generar un archivo de
construcción Ant build.xml mínimo con tareas para construir el
archivo jar especificado. En este caso, el parámetro #:source-dir
se
puede usar para especificar el subdirectorio de fuentes, con “src” como
valor predeterminado.
The #:main-class
parameter can be used with the minimal ant buildfile
to specify the main class of the resulting jar. This makes the jar file
executable. The #:test-include
parameter can be used to specify the
list of junit tests to run. It defaults to (list "**/*Test.java")
.
The #:test-exclude
can be used to disable some tests. It defaults to
(list "**/Abstract*.java")
, because abstract classes cannot be run as
tests.
El parámetro #:build-target
se puede usar para especificar la tarea
Ant que debe ser ejecutada durante la fase build
. Por defecto se
ejecuta la tarea “jar”.
Esta variable es exportada por (guix build-system
android-ndk)
. Implementa un procedimiento de construcción para paquetes
Android NDK (kit de desarrollo nativo) usando un proceso de construcción
específico de Guix.
El sistema de construcción asume que los paquetes instalan sus archivos de
interfaz pública (cabeceras) en el subdirectorio include de la salida
out
y sus bibliotecas en el subdirectorio lib de la salida
out
".
También se asume que la unión de todas las dependencias de un paquete no tiene archivos en conflicto.
En este momento no funciona la compilación cruzada - por lo que las bibliotecas y los archivos de cabecera se asumen que son locales.
These variables, exported by (guix build-system asdf)
, implement
build procedures for Common Lisp packages using
“ASDF”. ASDF is a system
definition facility for Common Lisp programs and libraries.
The asdf-build-system/source
system installs the packages in source
form, and can be loaded using any common lisp implementation, via ASDF.
The others, such as asdf-build-system/sbcl
, install binary systems in
the format which a particular implementation understands. These build
systems can also be used to produce executable programs, or lisp images
which contain a set of packages pre-loaded.
El sistema de construcción usa convenciones de nombres. Para paquetes
binarios, el paquete debería estar prefijado con la implementación lisp,
como sbcl-
para asdf-build-system/sbcl
.
Adicionalmente, el paquete de fuentes correspondiente debe etiquetarse
usando la misma convención que los paquetes python (vea Módulos Python), usando el prefijo cl-
.
In order to create executable programs and images, the build-side procedures
build-program
and build-image
can be used. They should be
called in a build phase after the create-asdf-configuration
phase, so
that the system which was just built can be used within the resulting
image. build-program
requires a list of Common Lisp expressions to
be passed as the #:entry-program
argument.
By default, all the .asd files present in the sources are read to
find system definitions. The #:asd-files
parameter can be used to
specify the list of .asd files to read. Furthermore, if the package
defines a system for its tests in a separate file, it will be loaded before
the tests are run if it is specified by the #:test-asd-file
parameter. If it is not set, the files <system>-tests.asd
,
<system>-test.asd
, tests.asd
, and test.asd
will be
tried if they exist.
If for some reason the package must be named in a different way than the
naming conventions suggest, or if several systems must be compiled, the
#:asd-systems
parameter can be used to specify the list of system
names.
Esta variable se exporta en (guix build-system cargo)
. Permite la
construcción de paquetes usando Cargo, la herramienta de construcción del
lenguaje de programación Rust.
Automáticamente añade rustc
y cargo
al conjunto de
entradas. Se puede especificar el uso de un paquete Rust distinto con el
parámetro #:rust
.
Las dependencias normales de cargo se añadirán a la definición del paquete a
través del parámetro #:cargo-inputs
como una lista de pares de nombre
y especificación, donde la especificación puede ser un paquete o una
definición de fuentes source
. Tenga en cuenta que la especificación
debe evaluar a una ruta o a un archivo comprimido con gzip que incluya un
archivo Cargo.toml
en su raíz, o será ignorado. De manera parecida,
las dependencias de desarrollo de cargo deben añadirse a la definición del
paquete a través del parámetro #:cargo-development-inputs
.
En su fase configure
, este sistema de construcción hará que cualquier
fuente de entrada especificada en los parámetros #:cargo-inputs
y
#:cargo-development-inputs
esté disponible para cargo. También
borrará cualquier archivo Cargo.lock
incluido para que sea recreado
por cargo
durante la fase build
de construcción. La fase
install
instala los binarios que el “crate” haya definido.
This variable is exported by (guix build-system chicken)
. It builds
CHICKEN Scheme modules, also called “eggs” or
“extensions”. CHICKEN generates C source code, which then gets compiled
by a C compiler, in this case GCC.
This build system adds chicken
to the package inputs, as well as the
packages of gnu-build-system
.
The build system can’t (yet) deduce the egg’s name automatically, so just
like with go-build-system
and its #:import-path
, you should
define #:egg-name
in the package’s arguments
field.
For example, if you are packaging the srfi-1
egg:
(arguments '(#:egg-name "srfi-1"))
Egg dependencies must be defined in propagated-inputs
, not
inputs
because CHICKEN doesn’t embed absolute references in compiled
eggs. Test dependencies should go to native-inputs
, as usual.
Esta variable se exporta en (guix build-system copy)
. Permite la
construcción de paquetes simples que no necesitan mucha compilación y en su
mayor parte dependen únicamente de la copia de archivos en distintas rutas.
Añade gran parte de los paquetes de gnu-build-system
al conjunto de
entradas. Por esta razón, copy-build-system
no necesita toda la
verborrea que habitualmente requiere trivial-build-system
.
Para simplificar más aún el proceso de instalación de archivos, se expone un
parámetro #:install-plan
para permitir a quien genera el paquete
especificar dónde van los distintos archivos. El plan de instalación
(#:install-plan
) es una lista de (fuente destino
[filtro])
. Los filtros son opcionales.
#:include
, #:include-regexp
, #:exclude
,
#:exclude-regexp
, únicamente se seleccionan los archivos instalados
dependiendo de los filtros. Cada filtro se especifica como una lista de
cadenas.
#:include
, se instalan todos los archivos de la ruta cuyo sufijo
corresponda con al menos uno de los elementos de la lista proporcionada.
#:include-regexp
se instalan todos los archivos cuyas
rutas relativas correspondan con al menos una de las expresiones regulares
en la lista proporcionada.
#:exclude
y #:exclude-regexp
son complementarios a sus equivalentes inclusivos. Sin opciones
#:include
, se instalan todos los archivos excepto aquellos que
correspondan con los filtros de exclusión. Si se proporcionan tanto
inclusiones como exclusiones, las exclusiones tienen efecto sobre los
resultados de las inclusiones.
En todos los casos, las rutas relativas a fuente se preservan dentro de destino.
Ejemplos:
("foo/bar" "share/my-app/")
: Instala bar en share/my-app/bar.
("foo/bar" "share/my-app/baz")
: Instala bar en share/my-app/baz.
("foo/" "share/my-app")
: Instala el contenido de foo dentro de share/my-app,
por ejemplo, instala foo/sub/file en share/my-app/sub/file.
("foo/" "share/my-app" #:include ("sub/file"))
: Instala únicamente foo/sub/file en
share/my-app/sub/file.
("foo/sub" "share/my-app" #:include ("file"))
: Instala foo/sub/file en
share/my-app/file.
Esta variable se exporta en (guix build-system clojure)
. Implementa
un procedimiento de construcción simple para paquetes
Clojure usando directamente compile
en
Clojure. La compilación cruzada no está disponible todavía.
Añade clojure
, icedtea
y zip
al conjunto de
entradas. Se pueden especificar paquetes diferentes con los parámetros
#:clojure
, #:jdk
y #:zip
, respectivamente.
Una lista de directorios de fuentes, directorios de pruebas y nombres de jar
pueden especificarse con los parámetros #:source-dirs
,
#:test-dirs
y #:jar-names
, respectivamente. El directorio de
compilación y la clase principal pueden especificarse con los parámetros
#:compile-dir
y #:main-class
, respectivamente. Otros
parámetros se documentan más adelante.
Este sistema de construcción es una extensión de ant-build-system, pero con las siguientes fases cambiadas:
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.
Esta variable se exporta en (guix build-system cmake)
. Implementa el
procedimiento de construcción para paquetes que usen la
herramienta de construcción CMake.
Automáticamente añade el paquete cmake
al conjunto de entradas. El
paquete usado se puede especificar con el parámetro #:cmake
.
El parámetro #:configure-flags
se toma como una lista de opciones a
pasar a cmake
. El parámetro #:build-type
especifica en
términos abstractos las opciones pasadas al compilador; su valor
predeterminado es "RelWithDebInfo"
(quiere decir “modo de entrega
con información de depuración”), lo que aproximadamente significa que el
código se compila con -O2 -g
, lo cual es el caso predeterminado en
paquetes basados en Autoconf.
Esta variable se exporta en (guix build-system dune)
. Permite la
construcción de paquetes mediante el uso de Dune, una herramienta de construcción para el lenguaje de programación
OCaml. Se implementa como una extensión de ocaml-build-system
que se
describe a continuación. Como tal, se pueden proporcionar los parámetros
#:ocaml
y #:findlib
a este sistema de construcción.
Automáticamente añade el paquete dune
al conjunto de entradas. El
paquete usado se puede especificar con el parámetro #:dune
.
No existe una fase configure
debido a que los paquetes dune no
necesitan ser configurados típicamente. El parámetro #:build-flags
se
toma como una lista de opciones proporcionadas a la orden dune
durante la construcción.
El parámetro #:jbuild?
puede proporcionarse para usar la orden
jbuild
en vez de la más reciente dune
durante la construcción
de un paquete. Su valor predeterminado es #f
.
El parámetro #:package
puede proporcionarse para especificar un
nombre de paquete, lo que resulta útil cuando un paquete contiene múltiples
paquetes y únicamente quiere construir uno de ellos. Es equivalente a
proporcionar el parámetro -p
a dune
.
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.
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
.
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
.
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-file-name
(which must be correctly capitalized).
For packages requiring shared library dependencies, you may need to write
the /deps/deps.jl file manually. It’s usually a line of const
variable = /gnu/store/library.so
for each dependency, plus a void function
check_deps() = nothing
.
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.
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.
Esta variable se exporta en (guix build-system minify)
. Implementa un
procedimiento de minificación para paquetes JavaScript simples.
Añade uglify-js
al conjunto de entradas y lo utiliza para comprimir
todos los archivos JavaScript en el directorio src. Un paquete de
minificación diferente puede especificarse con el parámetro
#:uglify-js
, pero se espera que el paquete escriba el código
minificado en la salida estándar.
Cuando los archivos JavaScript de entrada no se encuentran en el directorio
src, el parámetro #:javascript-files
puede usarse para
especificar una lista de nombres de archivo que proporcionar al minificador.
Esta variable se exporta en (guix build-system ocaml)
. Implementa un
procedimiento de construcción para paquetes OCaml,
que consiste en seleccionar el conjunto correcto de órdenes a ejecutar para
cada paquete. Los paquetes OCaml pueden esperar la ejecución de muchas
ordenes diferentes. Este sistema de construcción probará algunas de ellas.
Cuando el paquete tiene un archivo setup.ml presente en el nivel
superior, se ejecuta ocaml setup.ml -configure
, ocaml setup.ml
-build
y ocaml setup.ml -install
. El sistema de construcción asumirá
que este archivo se generó con http://oasis.forge.ocamlcore.org/
OASIS y se encargará de establecer el prefijo y la activación de las
pruebas si no se desactivaron. Puede pasar opciones de configuración y
construcción con #:configure-flags
y #:build-flags
,
respectivamente. El parámetro #:test-flags
puede usarse para cambiar
el conjunto de opciones usadas para activar las pruebas. El parámetro
#:use-make?
puede usarse para ignorar este sistema en las fases de
construcción e instalación.
Cuando el paquete tiene un archivo configure, se asume que es un
guión de configuración hecho a mano que necesita un formato de parámetros
diferente a los del sistema gnu-build-system
. Puede añadir más
opciones con el parámetro #:configure-flags
.
Cuando el paquete tiene un archivo Makefile (o #:use-make?
es
#t
), será usado y se pueden proporcionar más opciones para las fases
de construcción y e instalación con el parámetro #:make-flags
.
Por último, algunos paquetes no tienen estos archivos y usan unas
localizaciones de algún modo estándares para su sistema de construcción. En
este caso, el sistema de construcción ejecutará ocaml pkg/pkg.ml
o
ocaml pkg/build.ml
y se hará cargo de proporcionar la ruta del módulo
findlib necesario. Se pueden pasar opciones adicionales con el parámetro
#:build-flags
. De la instalación se hace cargo
opam-installer
. En este caso, el paquete opam
debe añadirse
al campo native-inputs
de la definición del paquete.
Fíjese que la mayoría de los paquetes OCaml asumen su instalación en el
mismo directorio que OCaml, lo que no es el comportamiento deseado en
guix. En particular, tratarán de instalar archivos .so en su
directorio de módulos, lo que normalmente es aceptable puesto que está bajo
el directorio del compilador de OCaml. No obstante, en guix estas
bibliotecas no se pueden instalar ahí, por lo que se usa
CAML_LD_LIBRARY_PATH
. Esta variable apunta a
lib/ocaml/site-lib/stubslibs y allí es donde se deben instalar las
bibliotecas .so.
Esta variable se exporta en (guix build-system python)
. Implementa el
procedimiento más o menos estándar de construcción usado por paquetes
Python, que consiste en la ejecución de python setup.py build
y
python setup.py install --prefix=/gnu/store/…
.
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
.
Esta variable se exporta en (guix build-system perl)
. Implementa el
procedimiento de construcción estándar para paquetes Perl, lo que o bien
consiste en la ejecución de perl Build.PL
--prefix=/gnu/store/…
, seguido de Build
y Build
install
; o en la ejecución de perl Makefile.PL
PREFIX=/gnu/store/…
, seguida de make
y make install
,
dependiendo de si Build.PL
o Makefile.PL
están presentes en la
distribución del paquete. El primero tiene preferencia si existen tanto
Build.PL
como Makefile.PL
en la distribución del paquete. Esta
preferencia puede ser invertida mediante la especificación del valor
#t
en el parámetro #:make-maker?
.
La invocación inicial de perl Makefile.PL
o perl Build.PL
pasa
a su vez las opciones especificadas por los parámetros
#:make-maker-flags
o #:module-build-flags
, respectivamente.
El paquete Perl usado puede especificarse con #:perl
.
This variable is exported by (guix build-system renpy)
. It
implements the more or less standard build procedure used by Ren’py games,
which consists of loading #:game
once, thereby creating bytecode for
it.
It further creates a wrapper script in bin/
and a desktop entry in
share/applications
, both of which can be used to launch the game.
Which Ren’py package is used can be specified with #:renpy
. Games
can also be installed in outputs other than “out” by using
#:output
.
Esta variable se exporta en (guix build-system qt)
. Está pensado para
usarse con aplicaciones que usen Qt o KDE.
Este sistema de construcción añade las dos fases siguientes a las definidas en cmake-build-system:
check-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
.
Esta variable se exporta en (guix build-system r)
. Implementa el
procedimiento de construcción usados por paquetes
R, lo que esencialmente es poco más que la
ejecución de ‘R CMD INSTALL --library=/gnu/store/…’ en un entorno
donde R_LIBS_SITE
contiene las rutas de todos los paquetes R de
entrada. Las pruebas se ejecutan tras la instalación usando la función R
tools::testInstalledPackage
.
This variable is exported by (guix build-system rakudo)
. It
implements the build procedure used by Rakudo
for Perl6 packages. It installs the package to
/gnu/store/…/NAME-VERSION/share/perl6
and installs the
binaries, library files and the resources, as well as wrap the files under
the bin/
directory. Tests can be skipped by passing #f
to the
tests?
parameter.
El paquete rakudo en uso puede especificarse con rakudo
. El paquete
perl6-tap-harness en uso durante las pruebas puede especificarse con
#:prove6
o eliminarse proporcionando #f
al parámetro
with-prove6?
. El paquete perl6-zef en uso durante las pruebas e
instalación puede especificarse con #:zef
o eliminarse proporcionando
#f
al parámetro with-zef?
.
Esta variable se exporta en (guix build-system texlive)
. Se usa para
construir paquetes TeX en modo de procesamiento de lotes con el motor
especificado. El sistema de construcción proporciona valor a la variable
TEXINPUTS
para encontrar todos los archivos de fuentes TeX en las
entradas.
Por defecto ejecuta luatex
en todos los archivos que terminan en
ins
. Un motor y formato diferente puede especificarse con el
parámetro #:tex-format
. Los diferentes objetivos de construcción
pueden especificarse con el parámetro #:build-targets
, que espera una
lista de nombres de archivo. El sistema de construcción añade únicamente
texlive-bin
y texlive-latex-base
(ambos desde (gnu
packages tex)
a las entradas. Ambos pueden forzarse con los parámetros
#:texlive-bin
y #:texlive-latex-base
respectivamente.
El parámetro #:tex-directory
le dice al sistema de construcción dónde
instalar los archivos construidos bajo el árbol texmf.
Esta variable se exporta en (guix build-system ruby)
. Implementa el
procedimiento de construcción de RubyGems usado por los paquetes Ruby, que
implica la ejecución de gem build
seguida de gem install
.
El campo source
de un paquete que usa este sistema de construcción
típicamente se refiere a un archivo gem, ya que este es el formato usado por
las desarrolladoras Ruby cuando publican su software. El sistema de
construcción desempaqueta el archivo gem, potencialmente parchea las
fuentes, ejecuta la batería de pruebas, vuelve a empaquetar el archivo gem y
lo instala. Adicionalmente, se puede hacer referencia a directorios y
archivadores tar para permitir la construcción de archivos gem no publicados
desde Git o un archivador tar de publicación de fuentes tradicional.
Se puede especificar el paquete Ruby usado mediante el parámetro
#:ruby
. Una lista de opciones adicionales pueden pasarse a la orden
gem
en el parámetro #:gem-flags
.
Esta variable se exporta en (guix build-system waf)
. Implementa un
procedimiento de construcción alrededor del guión waf
. Las fases
comunes—configure
, build
y install
—se implementan
pasando sus nombres como parámetros al guión waf
.
El guión waf
es ejecutado por el intérprete Python. El paquete Python
usado para la ejecución puede ser especificado con el parámetro
#:python
.
Esta variable se exporta en (guix build-system scons)
. Implementa en
procedimiento de construcción usado por la herramienta de construcción de
software SCons. Este sistema de construcción ejecuta scons
para
construir el paquete, scons test
para ejecutar las pruebas y después
scons install
para instalar el paquete.
Las opciones adicionales a pasar a scons
se pueden especificar con el
parámetro #:scons-flags
. Los objetivos predeterminados de
construcción (build) e instalación (install) pueden modificarse con
#:build-targets
y #:install-targets
respectivamente. La
versión de Python usada para ejecutar SCons puede especificarse
seleccionando el paquete SCons apropiado con el parámetro #:scons
.
Esta variable se exporta en (guix build-system haskell)
. Implementa
el procedimiento de construcción Cabal usado por paquetes Haskell, el cual
implica la ejecución de runhaskell Setup.hs configure
--prefix=/gnu/store/…
y runhaskell Setup.hs build
. En vez de
instalar el paquete ejecutando runhaskell Setup.hs install
, para
evitar el intento de registro de bibliotecas en el directorio de
solo-lectura del compilador en el almacén, el sistema de construcción usa
runhaskell Setup.hs copy
, seguido de runhaskell Setup.hs
register
. Además, el sistema de construcción genera la documentación del
paquete ejecutando runhaskell Setup.hs haddock
, a menos que se pasase
#:haddock? #f
. Parámetros opcionales de Haddock pueden proporcionarse
con la ayuda del parámetro #:haddock-flags
. Si el archivo
Setup.hs
no es encontrado, el sistema de construcción busca
Setup.lhs
a su vez.
El compilador Haskell usado puede especificarse con el parámetro
#:haskell
cuyo valor predeterminado es ghc
.
Esta variable se exporta en (guix build-system dub)
. Implementa el
procedimiento de construcción Dub usado por los paquetes D, que implica la
ejecución de dub build
y dub run
. La instalación se lleva a
cabo con la copia manual de los archivos.
El compilador D usado puede ser especificado con el parámetro #:ldc
cuyo valor predeterminado es ldc
.
Esta variable se exporta en (guix build-system emacs)
. Implementa un
procedimiento de instalación similar al propio sistema de empaquetado de
Emacs (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.
Esta variable se exporta en (guix build-system font)
. Implementa un
procedimiento de instalación para paquetes de fuentes donde las proveedoras
originales proporcionan archivos de tipografía TrueType, OpenType, etc.
precompilados que simplemente necesitan copiarse en su lugar. Copia los
archivos de tipografías a las localizaciones estándar en el directorio de
salida.
Esta variable se exporta en (guix build-system meson)
. Implementa el
procedimiento de construcción para paquetes que usan
Meson como su sistema de construcción.
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
.
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
).
Esta variable se exporta en (guix build-system node)
. Implementa el
procedimiento de construcción usado por Node.js,
que implementa una aproximación de la orden npm install
, seguida de
una orden npm test
.
El paquete Node.js usado para interpretar las órdenes npm
puede
especificarse a través del parámetro #:node
cuyo valor predeterminado
es node
.
Por último, para paquetes que no necesiten nada tan sofisticado se proporciona un sistema de construcción “trivial”. Es trivial en el sentido de que no proporciona prácticamente funcionalidad: no incorpora entradas implícitas y no tiene una noción de fases de construcción.
Esta variable se exporta en (guix build-system trivial)
.
Este sistema de construcción necesita un parámetro #:builder
. Este
parámetro debe ser una expresión Scheme que construya la(s) salida(s) del
paquete—como en build-expression->derivation
(véase build-expression->derivation
).
Rogamos que se inspeccionen los módulos (guix
build gnu-build-system)
para más detalles sobre las fases de construcción
Siguiente: Fases de construcción, Anterior: Definición de variantes de paquetes, Subir: Interfaz programática [Índice general][Índice]