Systèmes de construction (Manuel de référence de GNU Guix)

8.5 Systèmes de construction

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

Variable :gnu-build-system

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.

Variable :agda-build-system

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

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

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

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

Variable :ant-build-system

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.

Variable :android-ndk-build-system

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.

Variable :asdf-build-system/source

Variable :asdf-build-system/sbcl

Variable :asdf-build-system/ecl

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.

Variable :cargo-build-system

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.

Variable :chicken-build-system

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.

Variable :copy-build-system

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.

Lorsque source correspond à un fichier ou à un répertoire sans barre oblique, installez-le sur cible.
- Si target a une barre oblique, installez le nom de base source sous target.
- Sinon, installez source comme cible.
Lorsque source est un répertoire avec une barre oblique, ou lorsque des filtres sont utilisés, la barre oblique de target est implicite avec la même signification que ci-dessus.
- Sans filtres, installez le source complet contenu à cible.
- Avec filtres parmi #: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.
  - Avec #:include, installez tous les fichiers dont le suffixe de chemin correspond au moins un des éléments dans la liste donnée.
  - Avec #: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.
  - Les filtres #: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.
- When a package has multiple outputs, the #: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.

Variable :vim-build-system

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

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

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

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

Variable :clojure-build-system

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.

Variable :cmake-build-system

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.

Variable :composer-build-system

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

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

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

Variable :dune-build-system

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.

Variable :elm-build-system

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 :

Le système de construction se concentre sur les paquets au sens d’Elm : les projets Elm qui déclarent { "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 permet la coexistence simultané de plusieurs versions d’un paquet dans 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.
Nous ne pouvons pas encore lancer les tests des projets Elm parce que ni elm-test-rs ni l’exécuteur elm-test basé sur Node.js ne sont empaquetés dans Guix.

Variable :go-build-system

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.

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

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

Variable :glib-or-gtk-build-system

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.

Variable :guile-build-system

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.

Variable :julia-build-system

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.

Variable :maven-build-system

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.

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

Variable :minify-build-system

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.

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

Variable :ocaml-build-system

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.

Variable :python-build-system

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.

Variable :pyproject-build-system

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.

Variable :perl-build-system

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.

Variable :renpy-build-system

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.

Variable :qt-build-system

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.

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

Variable :rakudo-build-system

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

Variable :rebar-build-system

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.

Variable :texlive-build-system

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.

Variable :ruby-build-system

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.

Variable :waf-build-system

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.

Variable :zig-build-system

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

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

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

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

Variable :scons-build-system

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.

Variable :haskell-build-system

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.

Variable :dub-build-system

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.

Variable :emacs-build-system

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

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

Variable :meson-build-system

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

Variable :linux-module-build-system

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

Variable :node-build-system

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.

Variable :tree-sitter-build-system

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

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

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

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.

Variable :trivial-build-system

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

Variable :channel-build-system

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.