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 :
#:phasesCet 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-flagsC’est une liste de drapeaux (chaînes) passés au script
configure. Voir Définition des paquets, pour un exemple.
#:make-flagsCette 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-targetCette 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-referencesLorsque 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.
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.
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.
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 :
buildCette 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.
checkCette 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.
installCette 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-docCette 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.
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.
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-wrapLa 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-schemasLa 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-apache") "\")\n"))))
;; Il y a un fichier Julia pour chaque plateforme, on les remplace tous.
(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.
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-setupLa 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-wrapLa 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 :
unpackCette 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.
bootstrapconfigureIl n’y a ni phase bootstrap ni configure parce que les paquets
erlang n’ont pas besoin d’être configurés.
buildCette 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,
installCela 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.
Par défaut, elle lance luatex sur tous les fichiers qui se terminent
par ins. Un moteur et un format différent peuvent être spécifiés
avec l’argument #:tex-format. Plusieurs cibles de constructions
peuvent être indiquées avec l’argument #:build-targets qui attend une
liste de noms de fichiers. Le système de construction ajoute uniquement
texlive-bin et texlive-latex-base (de (gnu packages
tex) à la liste des entrées. Les deux peuvent être remplacés avec les
arguments #:texlive-bin et #:texlive-latex-base,
respectivement.
Le paramètre #:tex-directory dit au système de construction où
installer les fichiers construit dans l’arbre texmf.
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.
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 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 :
configureLa 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.
buildLa phase lance ninja pour construire le paquet en parallèle par
défaut, mais cela peut être changé avec #:parallel-build?.
checkLa 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.
installLa 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-runpathCette 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-wrapCette 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-schemasCette 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 :
configureCette phase configure l’environnement pour que le Makefile du noyau Linux puisse être utilisé pour construire le module du noyau externe.
buildCette phase utilise le Makefile du noyau Linux pour construire le module du noyau externe.
installCette 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.
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).
Le paquet qui en résulte est une instance de Guix d’un canal donné, comme
guix-time-machine le construirait.
Suivant: Phases de construction, Précédent: Écrire un manifeste, Monter: Interface de programmation [Table des matières][Index]