Suivant: Phases de construction, Précédent: Écrire un manifeste, Monter: Interface de programmation [Table des matières][Index]
Chaque définition de paquet définie un système de construction et des
arguments pour ce système de construction (voir Définition des paquets). Ce
champ build-system
représente la procédure de construction du paquet,
ainsi que des dépendances implicites pour cette procédure de construction.
Les systèmes de construction sont des objets
<build-system>
. L’interface pour les créer et les manipuler est
fournie par le module (guix build-system)
et les systèmes de
construction eux-mêmes sont exportés par des modules spécifiques.
Sous le capot, les systèmes de construction compilent d’abord des objets
paquets en sacs. Un sac est comme un paquet, mais avec moins de
décoration — en d’autres mots, un sac est une représentation à bas-niveau
d’un paquet, qui inclus toutes les entrées de ce paquet, dont certaines ont
été implicitement ajoutées par le système de construction. Cette
représentation intermédiaire est ensuite compilée en une dérivation
(voir Dérivations). Le package-with-c-toolchain
est un exemple
d’une manière de modifier les entrées implicites que le système de
construction d’un paquet récupère (voir package-with-c-toolchain
).
Les systèmes de construction acceptent une liste d’arguments
facultatifs. Dans les définitions de paquets, ils sont passés via le
champ arguments
(voir Définition des paquets). Ce sont typiquement des
arguments par mot-clef (voir keyword arguments in
Guile dans GNU Guile Reference Manual). La valeur de ces arguments est
habituellement évaluée dans la strate de construction — c.-à-d. par
un processus Guile lancé par le démon (voir Dérivations).
Le système de construction principal est le gnu-build-system
qui
implémente les procédures de construction standard pour les paquets GNU et
de nombreux autres. Il est fournit par le module (guix build-system
gnu)
.
gnu-build-system
représente le système de construction GNU et ses
variantes (voir configuration and makefile conventions dans GNU Coding Standards).
En résumé, les paquets qui l’utilisent sont configurés, construits et
installés avec la séquence ./configure && make && make check && make
install
habituelle. En pratique, des étapes supplémentaires sont souvent
requises. Toutes ces étapes sont séparées dans des phases
différentes. Voir Phases de construction pour plus d’informations sur les phases de
construction et comment les personnaliser.
En plus, ce système de construction s’assure que l’environnement « standard
» pour les paquets GNU est disponible. Cela inclus des outils comme GCC,
libc, Coreutils, Bash, Make, Diffutils, grep et sed (voir le module
(guix build-system gnu)
pour une liste complète). Nous les appelons
les entrées implicites d’un paquet parce que la définition du paquet
ne les mentionne pas.
Ce système de construction prend en charge un certain nombre de mot-clés,
qui peuvent être passés via le champ arguments
d’un paquet. Voici
certains des paramètres principaux :
#:phases
Cet argument spécifie le code du côté de la construction qui s’évalue en une liste d’association des phases de construction. Voir Phases de construction, pour plus d’informations.
#:configure-flags
C’est une liste de drapeaux (chaînes) passés au script
configure
. Voir Définition des paquets, pour un exemple.
#:make-flags
Cette liste de chaînes contient les drapeaux passés en argument aux
invocation de make
dans les phases build
, check
et
install
.
#:out-of-source?
Ce booléen, #f
par défaut, indique s’il faut lancer les constructions
dans un répertoire séparé de l’arborescence des sources.
Lorsque la valeur est vraie, la phase configure
crée un répertoire de
construction séparé, se déplace dedans et lance le script configure
à
partir de celui-ci. C’est utile pour les paquets qui en ont besoin, comme
glibc
.
#:tests?
Ce booléen, #t
par défaut, indique si la phase check
doit
lancer la suite de tests du paquet.
#:test-target
Cette chaîne, "check"
par défaut, donne le nom de la cible du
makefile à utiliser dans la phase check
.
#:parallel-build?
#:parallel-tests?
Ces booléens spécifient s’il faut construire, respectivement lancer la suite
de tests, en parallèle, avec le drapeau -j
de make
. Lorsque
la valeur est vraie, make
reçoit -jn
, où n est le
nombre spécifié dans l’option --cores de guix-daemon
ou
celle de la commande du client guix
(voir --cores).
#:validate-runpath?
Ce booléen, #t
par défaut, détermine s’il faut « valider » le
RUNPATH
des binaires ELF (les bibliothèques partagées .so
et
les exécutables) installés précédemment par la phase
install
. Voir la phase
validate-runpath
, pour plus de détails.
#:substitutable?
Ce booléen, #t
par défaut, indique si les sorties du paquet peuvent
être substituées — c.-à-d. si les utilisateur·rices peuvent obtenir des
substituts au lieu de les construire localement (voir Substituts).
#:allowed-references
#:disallowed-references
Lorsque la valeur est vraie, ces arguments doivent être une liste de dépendance qui ne doivent pas apparaître dans les dépendances des résultats de la construction. Si, à la fin de la construction, certaines de ces références sont retenues, le processus échoue.
C’est utile pour s’assurer qu’un paquet ne garde pas une référence par
erreur à ses entrées de construction, sis cela augmente par exemple la
taille de sa clôture (voir Invoquer guix size
).
La plupart des autres systèmes de construction prennent en charge ces mot-clés.
D’autres objets <build-system>
sont définis pour supporter d’autres
conventions et outils utilisés par les paquets de logiciels libres. Ils
héritent de la plupart de gnu-build-system
et diffèrent surtout dans
l’ensemble des entrées implicites ajoutées au processus de construction et
dans la liste des phases exécutées. Certains de ces systèmes de
construction sont listés ci-dessous.
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
.
Cette variable est exportée par (guix build-system ant)
. Elle
implémente la procédure de construction pour les paquets Java qui peuvent
être construits avec l’outil de construction
Ant.
Elle ajoute à la fois ant
et the kit de développement Java
(JDK) fournit par le paquet icedtea
à l’ensemble des entrées. Des
paquets différents peuvent être spécifiés avec les paramètres #:ant
et #:jdk
respectivement.
Lorsque le paquet d’origine ne fournit pas de fichier de construction Ant
acceptable, le paramètre #:jar-name
peut être utilisé pour générer un
fichier de construction Ant build.xml minimal, avec des tâches pour
construire l’archive jar spécifiée. Dans ce cas, le paramètre
#:source-dir
peut être utilisé pour spécifier le sous-répertoire des
sources, par défaut « src ».
Le paramètre #:main-class
peut être utilisé avec le fichier de
construction minimal pour spécifier la classe principale du jar. Cela rend
le fichier jar exécutable. Le paramètre #:test-include
peut être
utilisé pour spécifier la liste des tests junits à lancer. Il vaut par
défaut (list "**/*Test.java")
. Le paramètre #:test-exclude
peut être utilisé pour désactiver certains tests. Sa valeur par défaut est
(list "**/Abstract*.java")
, parce que les classes abstraites ne
peuvent pas être utilisées comme des tests.
Le paramètre #:build-target
peut être utilisé pour spécifier la tâche
Ant qui devrait être lancée pendant la phase build
. Par défaut la
tâche « jar » sera lancée.
Cette variable est exportée par (guix build-system android-ndk)
.
Elle implémente une procédure de construction pour les paquets du NDK
Android (native development kit) avec des processus de construction
spécifiques à Guix.
Le système de compilation suppose que les paquets installent leurs fichiers
d’interface publique (en-tête) dans le sous-répertoire include de la
sortie out
et leurs bibliothèques dans le sous-répertoire lib
de la sortie out
.
Il est aussi supposé que l’union de toutes les dépendances d’un paquet n’a pas de fichiers en conflit.
Pour l’instant, la compilation croisée n’est pas supportées — donc pour l’instant les bibliothèques et les fichiers d’en-têtes sont supposés être des outils de l’hôte.
Ces variables, exportées par (guix build-system asdf)
, implémentent
les procédures de constructions pour les paquets en Common Lisp qui
utilisent « ASDF ». ASDF est
un dispositif de définition de systèmes pour les programmes et les
bibliothèques en Common Lisp.
Le système asdf-build-system/source
installe les paquets au format
source qui peuvent être chargés avec n’importe quelle implémentation de
common lisp, via ASDF. Les autres, comme asdf-build-system/sbcl
,
installent des binaires au format qu’un implémentation particulière
comprend. Ces systèmes de constructions peuvent aussi être utilisés pour
produire des programmes exécutables ou des images lisp qui contiennent un
ensemble de paquets pré-chargés.
Le système de construction utilise des conventions de nommage. Pour les
paquets binaires, le nom du paquet devrait être préfixé par l’implémentation
lisp, comme sbcl-
pour asdf-build-system/sbcl
.
En plus, le paquet source correspondant devrait étiquetté avec la même
convention que les paquets Python (voir Modules Python), avec le préfixe
cl-
.
Pour créer des programmes exécutables et des images, les procédures côté
construction build-program
et build-image
peuvent être
utilisées. Elles devraient être appelées dans une phase de construction
après la phase create-asdf-configuration
pour que le système qui
vient d’être construit puisse être utilisé dans l’image créée.
build-program
requiert une liste d’expressions Common Lisp dans
l’argument #:entry-program
.
Par défaut, tous les fichiers .asd présents dans les sources sont lus
pour trouver les définitions du système. Le paramètre #:asd-file
peut
être utilisé pour préciser la liste des fichiers .asd à lire. En
outre, si le paquet définit un système pour ses tests dans un fichier
séparé, il sera chargé avant l’exécution des tests s’il est spécifié par le
paramètre #:test-asd-file
. S’il n’est pas défini, les fichiers
<system>-tests.asd
, <system>-test.asd
, tests.asd
et
test.asd
seront essayés s’ils existent.
Si pour quelque raison que ce soit le paquet doit être nommé d’une manière
différente de ce que la convention de nommage suggère, ou si plusieurs
systèmes doivent être compilés, le paramètre #:asd-systems
peut être
utilisé pour spécifier la liste des noms de systèmes.
Cette variable est exportée par (guix build-system cargo)
. Elle
supporte les construction de paquets avec Cargo, le système de construction
du langage de programmation Rust.
Cela ajoute rustc
et cargo
à l’ensemble des entrées. Un autre
paquet Rust peut être spécifié avec le paramètre #:rust
.
Les dépendances régulières de cargo doivent être ajoutées à la définition du
paquet comme avec les autres paquets ; celles qui ne sont requises qu’à la
construction dans « native-inputs », les autres dans « inputs ». Si vous
devez ajouter des crates sources alors vous devez les ajouter via le
paramètre #:cargo-inputs
sous la forme d’une liste de paires de noms
et de spécifications, où la spécification peut être un paquet ou une
définition de source. Notez que la spécification doit évaluer un chemin
vers une arhive gzippée qui inclut un fichier Cargo.toml
à sa racine,
sinon elle sera ignorée. De même, les dépendances de développement de cargo
doivent être ajoutées à la définition du paquet via le paramètre
#:cargo-development-inputs
.
Dans sa phase configure
, ce système de construction mettra à
disposition de cargo toutes les entrées sources spécifiées dans les
paramètres #:cargo-inputs
et #:cargo-development-inputs
. Il
supprimera également un fichier Cargo.lock
inclus, qui sera recréé
par cargo
pendant la phase build
. La phase package
lancera cargo package
pour créer un crate source réutilisable plus
tard. La phase install
installe les binaires définis par le crate. À
moins de définir install-source? #f
elle installera aussi un crate
source et les sources décompressées pour faciliter le travail avec les
paquets rust.
Cette variable est exportée par (guix build-system chicken)
. Elle
construit des modules CHICKEN Scheme, aussi
appelés « eggs » ou « extensions ». CHICKEN génère du code source C, qui est
ensuite compilé par un compilateur C, dans ce cas GCC.
Ce système de construction ajoute chicken
aux entrées du paquet, en
plus des paquets de gnu-build-system
.
Le système de construction ne peut pas (encore) déterminer le nom de l’egg
automatiquement, donc comme avec le go-build-system
et son
#:import-path
, vous devriez définir #:egg-name
dans le champ
arguments
du paquet.
Par exemple, si vous créez un paquet pour l’egg srfi-1
:
(arguments '(#:egg-name "srfi-1"))
Les dépendances des egg doivent être définies dans propagated-inputs
,
pas inputs
parce que CHICKEN n’inclut pas de références absolues dans
les eggs compilés. Les dépendances des tests doivent aller dans
native-inputs
, comme d’habitude.
Cette variable est exportée par (guix build-system copy)
. Il prend
en charge la construction de paquets simples qui ne nécessitent pas beaucoup
de compilation, la plupart du temps juste le déplacement de fichiers.
Cela ajoute une grande partie des paquets gnu-build-system
à
l’ensemble des entrées. De ce fait, le copy-build-system
n’a pas
besoin de tout le code passe-partout souvent nécessaire pour le
trivial-build-system
.
Pour simplifier davantage le processus d’installation des fichiers, un
argument #:install-plan
est exposé pour permettre au packager de
spécifier quels fichiers vont où. Le plan d’installation est une liste de
(source cible [filtres])
. Les filtres sont
facultatifs.
#:include
, #:include-regexp
, #:exclude
,
#:exclude-regexp
, seuls les fichiers sélectionnés sont installés en
fonction des filtres. Chaque filtre est spécifié par une liste de chaînes
de caractères.
#:include
, installez tous les fichiers dont le suffixe de chemin correspond
au moins un des éléments dans la liste donnée.
#:include-regexp
, installez tous les fichiers que le
les sous-chemins correspondent à au moins une des expressions régulières de
la liste donnée.
#:exclude
et #:exclude-regexp
sont le complément de leur homologue pour l’inclusion. Sans les drapeaux
#:include
, installez tous les fichiers sauf ceux qui correspondent
aux filtres d’exclusion. Si les inclusions et les exclusions sont toutes
deux spécifiées, les exclusions sont faites en complément des inclusions.
#:output
argument
can be used to specify which output label the files should be installed to.
Dans tous les cas, les chemins relatifs à source sont préservés dans cible.
Exemples :
("toto/titi" "share/mon-app/")
: Installer titi sur share/mon-app/titi.
("toto/titi" "share/mon-app/tata")
: Installer titi sur share/mon-app/tata.
("toto/" "share/mon-app")
: Installez le contenu de toto dans share/mon-app,
par exemple, installe toto/sub/file dans
share/mon-app/sub/file.
("toto/" "share/mon-app" #:include ("sub/file"))
: Installe seulement toto/sub/file vers
share/mon-app/sub/file.
("toto/sub" "share/mon-app" #:include ("file"))
: Installe toto/sub/file vers
share/mon-app/file.
("foo/doc" "share/my-app/doc" #:output "doc")
: Install
"foo/doc" to "share/my-app/doc" within the "doc"
output.
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
:
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.
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
(voir copy-build-system
).
#: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.
#: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.
#: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.
Cette variable est exportée par (guix build-system clojure)
. Elle
implémente une procédure de construction des paquets simple qui utilise le
bon vieux compile
de Clojure. La compilation croisée n’est pas
encore supportée.
Elle ajoute clojure
, icedtea
et zip
à l’ensemble des
entrées. Des paquets différents peuvent être spécifiés avec les paramètres
#:clojure
, #:jdk
et #:zip
.
Une liste de répertoires sources, de répertoires de tests et de noms de jar
peuvent être spécifiés avec les paramètres #:source-dirs
,
#:test-dirs
et #:jar-names
. Le répertoire de construction est
la classe principale peuvent être spécifiés avec les paramètres
#:compile-dir
et #:main-class
. Les autres paramètres sont
documentés plus bas.
Ce système de construction est une extension de ant-build-system
,
mais avec les phases suivantes modifiées :
build
Cette phase appelle compile
en Clojure pour compiler les fichiers
sources et lance jar
pour créer les fichiers jar à partir des
fichiers sources et des fichiers compilés en suivant la liste d’inclusion et
d’exclusion spécifiées dans #:aot-include
et #:aot-exclude
.
La liste d’exclusion a la priorité sur la liste d’inclusion. Ces listes
consistent en des symboles représentant des bibliothèque Clojure ou le mot
clef spécial #:all
, représentant toutes les bibliothèques Clojure
trouvées dans les répertoires des sources. Le paramètre
#:omit-source?
décide si les sources devraient être incluses dans les
fichiers jar.
check
Cette phase lance les tests en suivant les liste d’inclusion et d’exclusion
spécifiées dans #:test-include
et #:test-exclude
. Leur
signification est analogue à celle de #:aot-include
et
#:aot-exclude
, sauf que le mot-clef spécial #:all
signifie
maintenant toutes les bibliothèques Clojure trouvées dans les répertoires de
tests. Le paramètre #:tests?
décide si les tests devraient être
lancés.
install
Cette phase installe tous les fichiers jar précédemment construits.
En dehors de cela, le système de construction contient aussi la phase suivante :
install-doc
Cette phase installe tous les fichiers dans le répertoire de plus haut
niveau dont le nom correspond à %doc-regex
. On peut spécifier une
regex différente avec le paramètre #:doc-regex
. Tous les fichiers
(récursivement) dans les répertoires de documentations spécifiés dans
#:doc-dirs
sont aussi installés.
Cette variable est exportée par (guix build-system cmake)
. Elle
implémente la procédure de construction des paquets qui utilisent
l’outil de construction CMake.
Elle ajoute automatiquement le paquet cmake
à l’ensemble des
entrées. Le paquet utilisé peut être spécifié par le paramètre
#:cmake
.
Le paramètre #:configure-flags
est pris comme une liste de drapeaux à
passer à la commande cmake
. Le paramètre #:build-type
spécifie en termes abstrait les drapeaux passés au compilateur ; sa valeur
par défaut est "RelWithDebInfo"
(ce qui veut dire « mode public avec
les informations de débogage » en plus court), ce qui signifie en gros que
le code sera compilé avec -O2 -g
comme pour les paquets autoconf par
défaut.
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.
Cette variable est exportée par (guix build-system dune)
. Elle prend
en charge la construction des paquets qui utilisent
Dune, un outil de construction pour le langage
de programmation OCaml. Elle est implémentée comme une extension de
ocaml-build-system
décrit plus bas. En tant que tel, les paramètres
#:ocaml
et #:findlib
peuvent être passés à ce système de
construction.
Elle ajoute automatiquement le paquet dune
à l’ensemble des entrées.
Le paquet utilisé peut être spécifié par le paramètre #:dune
.
Il n’y a pas de phase configure
parce que les paquets dune n’ont
habituellement pas besoin d’être configurés. Le paramètre
#:build-flags
est interprété comme une liste de drapeaux pour la
commande dune
pendant la construction.
Le paramètre #:jbuild?
peut être passé pour utiliser la commande
jbuild
à la place de la commande dune
plus récente pour la
construction d’un paquet. Sa valeur par défaut est #f
.
Le paramètre #:package
peut être passé pour spécifié un nom de
paquet, ce qui est utile lorsqu’un paquet contient plusieurs paquets et que
vous voulez n’en construire qu’un. C’est équivalent à passer l’argument
-p
à dune
.
Cette variable est exportée par (guix build-system elm)
. Elle
implémente une procédure de construction pour les paquets
Elm qui ressemble à ‘elm install’.
Le système de construction ajoute un paquet qui contient le compilateur Elm
à l’ensemble des entrées. Le paquet de compilateur par défaut (actuellement
elm-sans-reactor
) peut être remplacé avec l’argument #:elm
. En
plus, les paquets Elm requis par le système de construction lui-même sont
ajoutés en tant qu’entrées implicites s’ils ne sont pas déjà présents : pour
supprimer ce comportement, utilisez l’argument
#:implicit-elm-package-inputs?
qui est surtout utile pour
l’armorçage.
Les "dependencies"
et "test-dependencies"
du fichier
elm.json d’un paquet Elm correspondent à propagated-inputs
et
inputs
, respectivement.
Elm a besoin d’une structure particulière pour les noms des paquets :
voir Paquets elm pour plus de détails, en particulier sur les outils
fournis par (guix build-system elm)
.
Il y a actuellement quelques limites notables à elm-build-system
:
{ "type": "package"}
dans
leur fichier elm.json. Utiliser elm-build-system
pour
construire des applications Elm (qui déclarent { "type":
"application" }
est possible, mais nécessite des modifications ad-hoc des
phases de construction. Par exemple, voir les définitions de l’application
d’exemple elm-todomvc
et du paquet elm
lui-même (parce que
l’interface de la commande ‘elm reactor’ est une application Elm).
ELM_HOME
, mais cela ne fonctionne pas encore bien avec
elm-build-system
. Cette limite affecte principalement les
applications Elm, parce qu’elles spécifient les versions exactes de leurs
dépendances, alors que les paquets Elm spécifient des intervalles de
versions prises en charge. Pour contourner le problème, les applications
d’exemple mentionnées plus haut utilisent la procédure
patch-application-dependencies
fournie par (guix build
elm-build-system)
pour réécrire leur fichier elm.json pour qu’ils se
réfèrent aux versions effectivement présentes dans l’environnement de
construction. Autrement, les transformations des paquets Guix
(voir Définition de variantes de paquets) peuvent aussi réécrire tout le graphe de
dépendance d’une application.
elm-test-rs
ni
l’exécuteur elm-test
basé sur Node.js ne sont empaquetés dans Guix.
Cette variable est exportée par (guix build-system go)
. Elle
implémente la procédure pour les paquets Go utilisant les
mécanismes de construction Go standard.
L’utilisateur doit fournir une valeur à la clef #:import-path
et,
dans certains cas, #:unpack-path
. Le
chemin d’import
correspond au chemin dans le système de fichiers attendu par le script de
construction du paquet et les paquets qui s’y réfèrent et fournit une
manière unique de se référer à un paquet Go. Il est typiquement basé sur
une combinaison de l’URI du code source du paquet et d’une structure
hiérarchique du système de fichier. Dans certains cas, vous devrez extraire
le code source du paquet dans une structure de répertoires différente que
celle indiquée par le chemin d’import et #:unpack-path
devrait être
utilisé dans ces cas-là.
Les paquets qui fournissent des bibliothèques Go devraient installer leur
code source dans la sortie du paquet. La clef #:install-source?
, qui
vaut #t
par défaut, contrôle l’installation du code source. Elle
peut être mise à #f
pour les paquets qui ne fournissent que des
fichiers exécutables.
Vous pouvez effectuer une compilation croisée des paquets et si vous voulez
une architecture ou un système d’exploitation spécifique alors vous pouvez
utiliser les mot-clés #:goarch
et #:goos
pour forcer le paquet
à être construit pour l’architecture et le système d’exploitation
donnés. Vous trouverez les combinaisons connues pour Go
dans leur
documentation.
Vous pouvez utiliser le mot-clé #:go
pour spécifier le paquet du
compilateur Go avec lequel construire le paquet.
Cette variable est exportée par (guix build-system glib-or-gtk)
.
Elle est conçue pour être utilisée par des paquets qui utilisent GLib ou
GTK+.
Ce système de construction ajoute les deux phases suivantes à celles
définies par gnu-build-system
:
glib-or-gtk-wrap
La phase glib-or-gtk-wrap
garantit que les programmes dans
bin/ sont capables de trouver les « schémas » GLib et
GTK+
modules. Cela est réalisé en enveloppant les programmes dans des scripts
de lancement qui définissent de manière appropriée les variables
d’environnement XDG_DATA_DIRS
et GTK_PATH
.
Il est possible d’exclure des sorties spécifiques de ce processus
d’enveloppage en listant leur nom dans le paramètre
#:glib-or-gtk-wrap-excluded-outputs
. C’est utile lorsqu’une sortie
est connue pour ne pas contenir de binaires GLib ou GTK+, et où l’enveloppe
ajouterait une dépendance inutile vers GLib et GTK+.
glib-or-gtk-compile-schemas
La phase glib-or-gtk-compile-schemas
s’assure que tous les
schémas GSettings de GLib sont compilés. La compilation est effectuée par
le programme glib-compile-schemas
. Il est fournit par le paquet
glib:bin
qui est automatiquement importé par le système de
construction. Le paquet glib
qui fournit
glib-compile-schemas
peut être spécifié avec le paramètre
#:glib
.
Ces deux phases sont exécutées après la phase install
.
Ce système de construction sert aux paquets Guile qui consistent
exclusivement en code Scheme et qui sont si simple qu’ils n’ont même pas un
makefile, sans parler d’un script configure. Il compile le code
Scheme en utilisant guild compile
(voir Compilation dans GNU Guile Reference Manual) et installe les fichiers .scm et
.go aux bons emplacements. Il installe aussi la documentation.
Ce système de construction supporte la compilation croisée en utilisant
l’option --target de guild compile
.
Les paquets construits avec guile-build-system
doivent fournir un
paquet Guile dans leur champ native-inputs
.
Cette variable est exportée par (guix build-system julia)
. Elle
implémente la procédure de compilation utilisée par les paquets
julia, qui est globalement similaire à
l’exécution de ‘julia -e 'using Pkg ; Pkg.add(package)'’ dans un
environnement où JULIA_LOAD_PATH
contient les chemins de toutes les
entrées des paquets Julia. Les tests sont effectués en appelant
/test/runtests.jl
.
Le nom et l’uuid du paquet Julia est lu dans le fichier
Project.toml. Ces valeurs peuvent être remplacées en passant
l’argument #:julia-package-name
(le nom doit être correctement
capitalisé) ou #:julia-package-uuid
.
Les paquets Julia gèrent généralement leurs dépendances binaires via
JLLWrappers.jl
, un paquet Julia qui crée un module (nommé d’après la
bibliothèque enveloppée suivie de _jll.jl
.
Pour ajouter le chemin vers les binaires _jll.jl
, vous devez corriger
les fichiers dans src/wrappers/, en remplaçant l’appel à la macro
JLLWrappers.@generate_wrapper_header
, en ajoutant un second argument
contenant le chemin du binaire dans le dépôt.
Par exemple, dans le paquets Julia MbedTLS, on ajoute un phase de construction (voir Phases de construction) pour insérer le nom de fichier absolu du paquet enveloppé MbedTLS :
(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$"))))
Certains paquets plus anciens qui n’utilisent pas encore Project.toml
nécessiteront aussi la création de ce fichier. Cela s’effectue en interne si
les arguments #:julia-package-name
et #:julia-package-uuid
sont fournis.
Cette variable est exportée par (guix build-system maven)
. Elle
implémente une procédure de construction pour les paquets
Maven. Maven est un outil de gestion des
dépendances et du cycle de vie pour Java. Un·e utilisateur·rice de Maven
spécifie les dépendances et les plugins dans un fichier pom.xml que
Maven lit. Lorsque Maven n’a pas l’une des dépendances ou l’un des plugins
dans son dépôt, il les télécharge et les utilise pour construire le paquet.
Le système de construction de maven garantit que maven n’essaiera pas de télécharger une dépendance en s’exécutant en mode hors ligne. Maven échouera si une dépendance est manquante. Avant de lancer Maven, le fichier pom.xml (et sous-projets) sont modifiés pour spécifier la version des dépendances et des plugins qui correspondent aux versions disponibles dans l’environnement de construction de guix. Les dépendances et plugins doivent être installés dans le faux dépôt maven à lib/m2, et sont liés par un lien symbolique à un dépôt approprié avant que maven ne soit lancé. Maven a pour instruction d’utiliser ce dépôt pour la construction et y installe les artefacts construits. Les fichiers modifiés sont copiés dans le répertoire lib/m2 de la sortie du paquet.
Vous pouvez spécifier un fichier pom.xml avec l’argument
#:pom-file
, ou bien laisser le système de construction utiliser le
fichier par défaut pom.xml dans les sources.
Dans le cas où vous avez besoin de spécifier manuellement une version de
dépendances, vous pouvez utiliser l’argument #:local-packages
. Il
prend une liste d’association dont la clé est le groupId du paquet et sa
valeur est une liste d’association où la clé est l’artefactId du paquet et
sa valeur est la version que vous souhaitez remplacer dans le fichier
pom.xml.
Certains paquets utilisent des dépendances ou des plugins qui ne sont pas
utiles au moment de l’exécution ou de la compilation dans Guix. Vous pouvez
modifier le fichier pom.xml pour les supprimer en utilisant
l’argument #:exclude
. Sa valeur est une liste d’association où la
clé est le groupId du plugin ou de la dépendance que vous voulez supprimer,
et la valeur est une liste d’artifactId que vous voulez supprimer.
Vous pouvez remplacer les paquets jdk
et maven
par défaut avec
l’argument correspondant, #:jdk
et #:maven
.
L’argument #:maven-plugins
est une liste de plugins maven utilisés
pendant la construction, avec le même format que le champ inputs
de
la déclaration du paquet. Sa valeur par défaut est
(default-maven-plugins)
qui est également exportée.
Cette variable est exportée par (guix build-system minetest)
. Elle
implémente une procédure de construction pour les mods de
Minetest qui consiste à copier du code
Lua, des images et d’autres ressources aux emplacements où Minetest
recherche des mods. Le système de construction minimise aussi les images PNG
et vérifie que Minetest peut charger le mod sans erreur.
Cette variable est exportée par (guix build-system minify)
. Elle
implémente une procédure de minification pour des paquets JavaScript
simples.
Elle ajoute uglify-js
à l’ensemble des entrées et l’utilise pour
compresser tous les fichiers JavaScript du répertoire src. Un
minifieur différent peut être spécifié avec le paramètre #:uglify-js
mais il est attendu que ce paquet écrive le code minifié sur la sortie
standard.
Lorsque les fichiers JavaScript d’entrée ne sont pas situés dans le
répertoire src, le paramètre #:javascript-files
peut être
utilisé pour spécifier une liste de noms de fichiers à donner au minifieur.
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.
Cette variable est exportée par (guix build-system ocaml)
. Elle
implémente une procédure de construction pour les paquets
OCaml qui consiste à choisir le bon ensemble de
commande à lancer pour chaque paquet. Les paquets OCaml peuvent demander
des commandes diverses pour être construit. Ce système de construction en
essaye certaines.
Lorsqu’un fichier setup.ml est présent dans le répertoire de plus
haut niveau, elle lancera ocaml setup.ml -configure
, ocaml
setup.ml -build
et ocaml setup.ml -install
. Le système de
construction supposera que ces fichiers ont été générés par
OASIS et prendra soin
d’initialiser le préfixe et d’activer les tests s’ils ne sont pas
désactivés. Vous pouvez passer des drapeaux de configuration et de
construction avec #:configure-flags
et #:build-flags
. La clef
#:test-flags
peut être passée pour changer l’ensemble des drapeaux
utilisés pour activer les tests. La clef #:use-make?
peut être
utilisée pour outrepasser ce système dans les phases de construction et
d’installation.
Lorsque le paquet a un fichier configure, il est supposé qu’il s’agit
d’un script configure écrit à la main qui demande un format différent de
celui de gnu-build-system
. Vous pouvez ajouter plus de drapeaux avec
la clef #:configure-flags
.
Lorsque le paquet a un fichier Makefile (ou #:use-make?
vaut
#t
), il sera utilisé et plus de drapeaux peuvent être passés à la
construction et l’installation avec la clef #:make-flags
.
Enfin, certains paquets n’ont pas ces fichiers mais utilisent un emplacement
plus ou moins standard pour leur système de construction. Dans ce cas, le
système de construction lancera ocaml pkg/pkg.ml
ou
pkg/build.ml
et prendra soin de fournir le chemin du module findlib
requis. Des drapeaux supplémentaires peuvent être passés via la clef
#:bulid-flags
. L’installation se fait avec
opam-installer
. Dans ce cas, le paquet opam
doit être
ajouté au champ native-inputs
de la définition du paquet.
Remarquez que la plupart des paquets OCaml supposent qu’ils seront installés
dans le même répertoire qu’OCaml, ce qui n’est pas ce que nous voulons faire
dans Guix. En particulier, ils installeront leurs fichiers .so dans
leur propre répertoire de module, ce qui est normalement correct puisqu’il
s’agit du répertoire du compilateur OCaml. Dans Guix en revanche, ces
bibliothèques ne peuvent pas y être trouvées et on utilise
CAML_LD_LIBRARY_PATH
à la place. Cette variable pointe vers
lib/ocaml/site-lib/stubslibs et c’est là où les bibliothèques
.so devraient être installées.
Cette variable est exportée par (guix build-system python)
. Elle
implémente la procédure de construction plus ou moins standard utilisée pour
les paquets Python, qui consiste à lancer python setup.py build
puis
python setup.py install --prefix=/gnu/store/…
.
Pour les paquets qui installent des programmes autonomes Python dans
bin/
, elle prend soin d’envelopper ces binaires pour que leur
variable d’environnement GUIX_PYTHONPATH
pointe vers toutes les
bibliothèques Python dont ils dépendent.
Le paquet Python utilisé pour effectuer la construction peut être spécifié
avec le paramètre #:python
. C’est une manière utile de forcer un
paquet à être construit avec une version particulière de l’interpréteur
python, ce qui peut être nécessaire si le paquet n’est compatible qu’avec
une version de l’interpréteur.
Par défaut, guix appelle setup.py
sous le contrôle de
setuptools
, tout comme pip
le fait. Certains paquets ne
sont pas compatibles avec setuptools (et pip), vous pouvez donc le
désactiver en réglant le paramètre #:use-setuptools?
sur #f
.
Si la sortie "python"
est disponible, le paquet y est installé au
lieu de la sortie "out"
par défaut. C’est utile pour les paquets qui
incluent un paquet Python seulement comme partie du logiciel, et donc qu’il
faut combiner les phases de python-build-system
avec celles d’un
autre système de construction. Les liaisons Python sont un cas courant.
C’est une variable exportée par guix build-system pyproject
. Elle est
basée sur python-build-system et ajoute la prise en charge de
pyproject.toml et PEP
517. Elle prend aussi en charge plusieurs moteurs de construction et
cadriciels de test.
L’API est un peu différente de celle de python-build-system :
#:use-setuptools?
et #:test-target
sont supprimés.
#:build-backend
est ajouté. Sa valeur par défaut est #false
et
le système essaiera de deviner le moteur approprié en fonction de
pyproject.toml.
#:test-backend
est ajouté. Sa valeur par défaut est #false
et
le système essaiera de deviner un moteur de test approprié en fonction de ce
qui est disponible dans les entrées du paquet.
#:test-flags
est ajouté. La valeur par défaut est '()
. Ces
drapeaux sont passés en argument à la commande de test. Remarquez que les
drapeaux pour la sortie verbeuse sont toujours activés pour les moteurs pris
en charge.
Il est considéré comme « expérimental » dans le sens où les détails d’implémentation ne sont pas encore figés, mais nous vous encourageons à l’essayer pour les nouveaux projets Python (même ceux qui utilisent setup.py). L’API pourrait changer mais les changements provoquant des problèmes dans le canal Guix seront gérés.
Ce système de construction finira par être obsolète et fusionné dans python-build-system, sans doute au courant de l’année 2024.
Cette variable est exportée par (guix build-system perl)
. Elle
implémente la procédure de construction standard des paquets Perl, qui
consiste soit à lancer perl Build.PL --prefix=/gnu/store/…
,
suivi de Build
et Build install
; ou à lancer perl
Makefile.PL PREFIX=/gnu/store/…
, suivi de make
et make
install
, en fonction de la présence de Build.PL
ou
Makefile.PL
dans la distribution du paquet. Le premier a la
préférence si Build.PL
et Makefile.PL
existent tous deux dans
la distribution du paquet. Cette préférence peut être inversée en
spécifiant #t
pour le paramètre #:make-maker?
.
L’invocation initiale de perl Makefile.PL
ou perl Build.PL
passe les drapeaux spécifiés par le paramètre #:make-maker-flags
ou
#:module-build-flags
, respectivement.
Le paquet Perl utilisé peut être spécifié avec #:perl
.
Cette variable est exportée par (guix build-system renpy)
. Elle
implémente la procédure de construction plus ou moins standard utilisée pour
les jeux Ren’py, qui consiste à charger #:game
une fois, et donc à
créer le bytecode pour le jeu.
Elle crée aussi un script enveloppe dans bin/
et une entrée de bureau
dans share/applications
, tous deux pouvant être utilisés pour lancer
le jeu.
Le paquet Ren’py utilisé peut être spécifié avec #:renpy
. Les jeux
peuvent aussi être installé dans des sorties différentes de « out » avec
#:output
.
Cette variable est exportée par (guix build-system qt)
. Elle est
destinée à être employée avec des applications utilisant Qt ou KDE.
Ce système de construction ajoute les deux phases suivantes à celles
définies par gnu-build-system
:
check-setup
La phase check-setup
prépare l’environnement pour l’exécution des
contrôles tels qu’ils sont couramment utilisés par les programmes de test
Qt. Pour l’instant, elle ne définit que quelques variables d’environnement
: QT_QPA_PLATFORM=offscreen
, DBUS_FATAL_WARNINGS=0
et
CTEST_OUTPUT_ON_FAILURE=1
.
Cette phase est ajoutée avant la phase check
. C’est une phase
distincte pour faciliter l’ajustement si nécessaire.
qt-wrap
La phase qt-wrap
recherche les chemins des plugins Qt5, les chemins
QML et certains XDG dans les entrées et sorties. Si un chemin est trouvé,
tous les programmes des répertoires bin/, sbin/,
libexec/ et lib/libexec/ de la sortie sont enveloppés dans des
scripts définissant les variables d’environnement nécessaires.
Il est possible d’exclure des sorties de paquets spécifiques de ce processus
d’emballage en listant leurs noms dans le paramètre
#:qt-wrap-excluded-outputs
. Ceci est utile lorsqu’une sortie est
connue pour ne pas contenir de binaires Qt, et où le wrapping ajouterait
gratuitement une dépendance de cette sortie à Qt, KDE, ou autre.
Cette phase est exécutée après la phase install
.
Cette variable est exportée par (guix build-system r)
. Elle
implémente la procédure de compilation utilisée par les paquets
R, qui consiste en substance à exécuter
‘R CMD INSTALL --library=/gnu/store/…’ dans un environnement où
R_LIBS_SITE
contient les chemins de toutes les entrées des paquets R.
Les tests sont exécutés après l’installation en utilisant la fonction R
tools::testInstalledPackage
.
Cette variable est exportée par (guix build-system rakudo)
. Elle
implémente la procédure de construction utilisée par
Rakudo pour les paquets
Perl6. Elle installe le paquet dans
/gnu/store/…/NOM-VERSION/share/perl6
et installe les binaires,
les fichiers de bibliothèques et les ressources, et enveloppe les fichiers
dans le répertoire bin/
. Les tests peuvent être passés en indiquant
#f
au paramètre tests?
.
Le paquet rakudo utilisé peut être spécifié avec rakudo
. Le paquet
perl6-tap-harness utilisé pour les tests peut être spécifié avec
#:prove6
ou supprimé en passant #f
au paramètre
with-prove6?
. Le paquet perl6-zef utilisé pour les tests et
l’installation peut être spécifié avec #:ef
ou supprimé en passant
#f
au paramètre with-zef?
.
Cette variable est exportée par (guix build-system rebar)
. Elle
implémente une procédure de construction pour
rebar3, un système de construction pour les
programmes écrits en Erlang.
Elle ajoute à la fois rebar3
et erlang
à l’ensemble des
entrées. Des paquets différents peuvent être spécifiés avec les paramètres
#:rebar
et #:erlang
, respectivement.
Ce système de construction est basé sur gnu-build-system, mais avec les phases suivantes modifiées :
unpack
Cette phase, après avoir déballé les sources comme le fait le
gnu-build-system
, vérifie qu’un fichier contents.tar.gz
existe
au plus haut niveau des sources. Si ce fichier existe, il sera aussi
déballé. Cela facilite la gestion des paquets hébergés sur
https://hex.pm/, le dépôt des paquets Erlang et Elixir.
bootstrap
configure
Il n’y a ni phase bootstrap
ni configure
parce que les paquets
erlang n’ont pas besoin d’être configurés.
build
Cette phase lance rebar3 compile
avec les drapeaux listés dans
#:rebar-flags
.
check
À moins que #:tests? #f
ne soit passé, cette phase lance rebar3
eunit
, ou une cible spécifiée avec #:test-target
, avec les drapeaux
listés dans #:rebar-flags
,
install
Cela installe les fichiers créés dans le profil default, ou un autre
profil spécifié avec #:install-profile
.
Cette variable est exportée par (guix build-system texlive)
. Elle
est utilisée pour construire des paquets TeX en mode batch avec le moteur
spécifié. Le système de construction initialise la variable TEXINPUTS
pour trouver tous les fichiers source TeX dans ses entrées.
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
.
Cette variable est exportée par (guix build-system ruby)
. Elle
implémenter la procédure de construction RubyGems utilisée par les paquets
Ruby qui consiste à lancer gem build
suivi de gem install
.
Le champ source
d’un paquet qui utilise ce système de construction
référence le plus souvent une archive gem, puisque c’est le format utilisé
par les personnes qui développent en Ruby quand elles publient leur
logiciel. Le système de construction décompresse l’archive gem,
éventuellement en corrigeant les sources, lance la suite de tests,
recompresse la gemme et l’installe. En plus, des répertoires et des
archives peuvent être référencés pour permettre de construire des gemmes qui
n’ont pas été publiées depuis Git ou une archive de sources traditionnelle.
Le paquet Ruby utilisé peut être spécifié avec le paramètre #:ruby
.
Une liste de drapeaux supplémentaires à passer à la commande gem
peut être spécifiée avec le paramètre #:gem-flags
.
Cette variable est exportée par (guix build-system waf)
. Elle
implémente une procédure de construction autour du script waf
. Les
phases usuelles — configure
, build
et install
— sont
implémentée en passant leur nom en argument au script waf
.
Le script waf
est exécuté par l’interpréteur Python. Le paquet
Python utilisé pour lancer le script peut être spécifié avec le paramètre
#:python
.
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.
Cette variable est exportée par (guix build-system scons)
. Elle
implémente la procédure de construction utilisée par l’outil de construction
SCons. Ce système de construction lance scons
pour construire le
paquet, scons test
pour lancer les tests puis scons install
pour installer le paquet.
Des drapeaux supplémentaires à passer à scons
peuvent être spécifiés
avec le paramètre #:scons-flags
. Les cibles de construction et
d’installation par défaut peuvent être remplacées respectivement par les
paramètres #:build-targets
et #:install-targets
. La version
de Python utilisée pour exécuter SCons peut être spécifiée en sélectionnant
le paquet SCons approprié avec le paramètre #:scons
.
Cette variable est exportée par (guix build-system haskell)
. Elle
implémente la procédure de construction Cabal utilisée par les paquets
Haskell, qui consiste à lancer runhaskell Setup.hs configure
--prefix=/gnu/store/…
et runhaskell Setup.hs build
. Plutôt
que d’installer le paquets en lançant runhaskell Setup.hs install
,
pour éviter d’essayer d’enregistrer les bibliothèques dans le répertoire du
dépôt en lecture-seule du compilateur, le système de construction utilise
runhaskell Setup.hs copy
, suivi de runhaskell Setup.hs
register
. En plus, le système de construction génère la documentation du
paquet en lançant runhaskell Setup.hs haddock
, à moins que
#:haddock? #f
ne soit passé. Des paramètres facultatifs pour Haddock
peuvent être passés à l’aide du paramètre #:haddock-flags
. Si le
fichier Setup.hs
n’est pas trouvé, le système de construction
cherchera Setup.lhs
à la place.
Le compilateur Haskell utilisé peut être spécifié avec le paramètre
#:haskell
qui a pour valeur par défaut ghc
.
Cette variable est exportée par (guix build-system dub)
. Elle
implémente la procédure de construction Dub utilisée par les paquets D qui
consiste à lancer dub build
et dub run
. L’installation est
effectuée en copiant les fichiers manuellement.
Le compilateur D utilisé peut être spécifié avec le paramètre #:ldc
qui vaut par défaut ldc
.
Cette variable est exportée par (guix build-system emacs)
. Elle
implémente une procédure d’installation similaire au système de gestion de
paquet d’Emacs lui-même (voir Packages dans The GNU Emacs Manual).
Cela crée d’abord le fichier
, puis
compile tous les fichiers Emacs Lisp en bytecode. Contrairement au système
de gestion de paquets d’Emacs, les fichiers de documentation info sont
déplacés dans le répertoire standard et le fichier dir est supprimé.
Les fichiers du paquet Elisp sont directement installés sous
share/emacs/site-lisp.
package
-autoloads.el
Cette variable est exportée par (guix build-system font)
. Elle
implémente une procédure d’installation pour les paquets de polices où des
fichiers de polices TrueType, OpenType, etc. sont fournis en amont et
n’ont qu’à être copiés à leur emplacement final. Elle copie les fichiers de
polices à l’emplacement standard dans le répertoire de sortie.
Cette variable est exportée par (guix build-system meson)
. Elle
implémente la procédure de construction des paquets qui utilisent
Meson comme système de construction.
Elle ajoute à la fois Meson et Ninja à
l’ensemble des entrées, et ils peuvent être modifiés avec les paramètres
#:meson
et #:ninja
si requis.
Ce système de construction est une extension de gnu-build-system
,
mais avec les phases suivantes modifiées pour Meson :
configure
La phase lance meson
avec les drapeaux spécifiés dans
#:configure-flags
. Le drapeau --buildtype est toujours
défini à debugoptimized
à moins qu’autre chose ne soit spécifié dans
#:build-type
.
build
La phase lance ninja
pour construire le paquet en parallèle par
défaut, mais cela peut être changé avec #:parallel-build?
.
check
La phase lance ‘meson test’ avec un ensemble d’options de base qui ne
peuvent pas être modifiées. Cette base d’options peut être étendue avec
l’argument #:test-options
, par exemple pour choisir ou passer une
suite de test spécifique.
install
La phase lance ninja install
et ne peut pas être changée.
En dehors de cela, le système de construction ajoute aussi la phase suivante :
fix-runpath
Cette phase s’assure que tous les binaire peuvent trouver les bibliothèques
dont ils ont besoin. Elle cherche les bibliothèques requises dans les
sous-répertoires du paquet en construction et les ajoute au RUNPATH
là où c’est nécessaire. Elle supprime aussi les références aux
bibliothèques laissées là par la phase de construction par meson
comme les dépendances des tests, qui ne sont pas vraiment requises pour le
programme.
glib-or-gtk-wrap
Cette phase est la phase fournie par glib-or-gtk-build-system
et
n’est pas activée par défaut. Elle peut l’être avec #:glib-or-gtk?
.
glib-or-gtk-compile-schemas
Cette phase est la phase fournie par glib-or-gtk-build-system
et
n’est pas activée par défaut. Elle peut l’être avec #:glib-or-gtk?
.
linux-module-build-system
permet de construire des modules du noyau
Linux.
Ce système de construction est une extension de gnu-build-system, mais avec les phases suivantes modifiées :
configure
Cette phase configure l’environnement pour que le Makefile du noyau Linux puisse être utilisé pour construire le module du noyau externe.
build
Cette phase utilise le Makefile du noyau Linux pour construire le module du noyau externe.
install
Cette phase utilise le Makefile du noyau Linux pour installer le module du noyau externe.
Il est possible et utile de spécifier le noyau Linux à utiliser pour
construire le module (sous la forme arguments
d’un paquet utilisant
le linux-module-build-system
, utilisez la clé #:linux
pour le
spécifier).
Cette variable est exportée par (guix build-system node)
. Elle
implémente la procédure de compilation utilisée par
Node.js, qui implémente une approximation de la
commande npm install
, suivie d’une commande npm test
.
Le paquet Node.js utilisé pour interpréter les commandes npm
peut
être spécifié avec le paramètre #:node
dont la valeur par défaut est
node
.
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.
Enfin, pour les paquets qui n’ont pas besoin de choses sophistiquées, un système de construction « trivial » est disponible. Il est trivial dans le sens où il ne fournit en gros aucun support : il n’apporte pas de dépendance implicite, et n’a pas de notion de phase de construction.
Cette variable est exportée par (guix build-system trivial)
.
Ce système de construction requiert un argument #:builder
. Cet
argument doit être une expression Scheme qui construit la sortie du paquet —
comme avec build-expression->derivation
(voir build-expression->derivation
).
Cette variable est exportée par (guix build-system channel)
.
Ce système de construction est surtout conçu pour usage interne. Pour
utiliser ce système de construction, un paquet doit avoir une spécification
de canal dans son champ source
(voir Canaux); autrement, sa
source doit être un nom de répertoire, auquel cas un argument
#:commit
supplémentaire doit être fournit pour spécifier le commit à
construire (une chaine hexadécimale).
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.
Suivant: Phases de construction, Précédent: Écrire un manifeste, Monter: Interface de programmation [Table des matières][Index]