Suivant: , Précédent: , Monter: Invoquer guix build   [Table des matières][Index]


9.1.2 Options de transformation de paquets

Un autre ensemble d’options de la ligne de commande supportés par guix build et aussi guix package sont les options de transformation de paquets. Ce sont des options qui rendent possible la définition de variantes de paquets — par exemple, des paquets construit à partir de sources différentes. C’est une manière simple de créer des paquets personnalisés à la volée sans avoir à taper les définitions de variantes de paquets (voir Définition des paquets).

Les options de transformation des paquets sont préservées dans les mises à jour : guix upgrade tente d’appliquer aux paquets mis à jour les options de transformation initialement utilisées lors de la création du profil.

Les options disponibles sont énumérées ci-dessous. La plupart des commandes les prennent en charge, ainsi qu’une option --help-transform qui liste toutes les options disponibles et un synopsis (ces options ne sont pas affichées dans la sortie --help par souci de concision).

--with-source=source
--with-source=paquet=source
--with-source=paquet@version=source

Utilise source comme la source de paquet, et version comme son numéro de version. source doit être un nom de fichier ou une URL, comme pour guix download (voir Invoquer guix download).

Lorsque paquet est omis, la commande utilisera le nom de paquet spécifié par la base de source — p. ex. si source est /src/guix-2.0.10.tar.gz, le paquet correspondant est guile.

De même, lorsque version est omis, la chaîne de version est inférée à partir de source ; dans l’exemple précédent, il s’agit de 2.0.10.

Cette option permet aux utilisateurs d’essayer des version des paquets différentes de celles fournies par la distribution. L’exemple ci-dessous télécharge ed-1.7.tar.g depuis un miroir GNU et l’utilise comme source pour le paquet ed :

guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz

En tant que développeur·euse, --with-source permet de tester facilement des version bêta :

guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz

… ou pour construire un dépôt de gestion de version dans un environnement vierge :

$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=guix@1.0=./guix
--with-input=paquet=remplaçant

Remplace la dépendance sur paquet par une dépendance à remplaçant. paquet doit être un nom de paquet et remplaçant doit être une spécification de paquet comme guile ou guile@1.8.

Par exemple, la commande suivante construit Guix, mais remplace sa dépendance à la version stable actuelle de Guile par une dépendance à une ancienne version de Guile, guile@2.0 :

guix build --with-input=guile=guile@2.0 guix

C’est un remplacement récursif profond. Donc dans cet exemple, à la fois guix et ses dépendances guile-json (qui dépend aussi de guile) sont reconstruits avec guile@2.0.

Cette option est implémentée avec la procédure Scheme package-input-rewriting (voir package-input-rewriting).

--with-graft=paquet=remplaçant

Cette option est similaire à --with-input mais avec une différence importante : plutôt que de reconstruire la chaîne de dépendance complète, remplaçant est construit puis greffé sur les binaires qui référençaient initialement paquet. Voir Mises à jour de sécurité, pour plus d’information sur les greffes.

Par exemple, la commande ci-dessous greffe la version 3.5.4 de GnuTLS sur Wget et toutes ses dépendances, en remplaçant les références à la version actuelle de GnuTLS à laquelle ils se réfèrent actuellement :

guix build --with-graft=gnutls=gnutls@3.5.4 wget

Cela a l’avantage d’être bien plus rapide que de tout reconstruire. Mais il y a un piège : cela ne fonctionne que si paquet et remplaçant sont strictement compatibles — par exemple, s’ils fournissent une bibliothèque, l’interface binaire applicative (ABI) de ces bibliothèques doivent être compatibles. Si remplaçant est incompatible avec paquet, alors le paquet qui en résulte peut devenir inutilisable. À utiliser avec précaution !

--with-debug-info=paquet

Construire paquet de manière à préserver ses informations de débogage et les greffer sur les paquets qui en dépendent. Cela est utile si paquet ne fournit pas déjà les informations de débogage sous forme de sortie debug (voir Installer les fichiers de débogage).

Par exemple, supposons que vous subissiez un plantage de Inkscape et que vous vouliez voir ce qui se passe dans GLib, une bibliothèque au fond du graphe de dépendance d’Inkscape. GLib n’a pas de sortie debug, donc le débogage est difficile. Heureusement, vous reconstruisez la GLib avec les informations de débogage et vous l’installez dans Inkscape :

guix install inkscape --with-debug-info=glib

Seule GLib doit être recompilée, ce qui prend un temps raisonnable. Voir Installer les fichiers de débogage, pour plus d’informations.

Remarque : Sous le capot, cette option fonctionne en passant par le ‘#:strip-binaries ? #f’ au système de construction du paquet qui nous intéresse (voir Systèmes de construction). La plupart des systèmes de compilation supportent cette option, mais certains ne le font pas. Dans ce cas, une erreur se produit.

De même, si un paquet C/C++ est construit sans -g (ce qui est rarement le cas), les informations de débogage resteront indisponibles même si #:strip-binaries? est faux.

--with-c-toolchain=package=toolchain

Cette option modifie la compilation de package et de tout ce qui en dépend afin qu’ils soient construits avec toolchain au lieu de la chaîne d’outils GNU par défaut pour C/C++.

Regardez cet exemple :

guix build octave-cli \
  --with-c-toolchain=fftw=gcc-toolchain@10 \
  --with-c-toolchain=fftwf=gcc-toolchain@10

La commande ci-dessus construit une variante des paquets fftw et fftwf en utilisant la version 10 de gcc-toolchain au lieu de la chaîne d’outils par défaut, puis construit une variante de l’interface en ligne de commande GNU Octave en les utilisant. GNU Octave lui-même est également construit avec gcc-toolchain@10.

Cet autre exemple construit la bibliothèque Hardware Locality (hwloc) et ses dépendances jusqu’à intel-mpi-benchmarks avec le compilateur Clang C :

guix build --with-c-toolchain=hwloc=clang-toolchain \
           intel-mpi-benchmarks

Remarque : Il peut y avoir des incompatibilités d’interface binaire d’application (ABI) entre les chaînes d’outils. Cela est particulièrement vrai pour la bibliothèque standard C++ et les bibliothèques de support d’exécution telles que celle d’OpenMP. En reconstruisant toutes les dépendances avec la même chaîne d’outils, --with-c-toolchain minimise les risques d’incompatibilité mais ne peut pas les éliminer entièrement. Choisissez package judicieusement.

--with-git-url=paquet=url

Construire paquet depuis le dernier commit de la branche master du dépôt sur url. Les sous-modules Git du dépôt sont récupérés, récursivement.

Par exemple, la commande suivante construit la bibliothèque Python NumPy avec le dernier commit de la branche master de Python lui-même :

guix build python-numpy \
  --with-git-url=python=https://github.com/python/cpython

Cette option peut aussi être combinée avec --with-branch ou --with-commit (voir plus bas).

Évidemment, comme cela utilise le dernier commit d’une branche donnée, le résultat d’une telle commande varie avec le temps. Néanmoins c’est une manière pratique pour reconstruire des piles logicielles entières avec le dernier commit d’un ou plusieurs paquets. C’est particulièrement pratique dans le contexte d’une intégration continue.

Les clones sont gardés dans un cache dans ~/.cache/guix/checkouts pour accélérer les accès consécutifs au même dépôt. Vous pourriez vouloir le nettoyer de temps en temps pour récupérer de l’espace disque.

--with-branch=paquet=branche

Construire paquet à partir du dernier commit de la branche. Si le champ source de paquet est une origine avec la méthode git-fetch (voir référence des origines) ou un objet git-checkout, l’URL du dépôt est récupérée à partir de cette source. Sinon, vous devez utiliser --with-git-url pour spécifier l’URL du dépôt Git.

Par exemple, la commande suivante construit guile-sqlite3 à partir du dernier commit de sa branche master, puis construit guix (qui en dépend) et cuirass (qui dépend de guix) avec cette construction spécifique de guile-sqlite3 :

guix build --with-branch=guile-sqlite3=master cuirass
--with-commit=paquet=commit

Cela est similaire à --with-branch, sauf qu’elle construite à partir de commit au lieu du sommet d’une branche. commit doit être un identifiant SHA1 de commit Git valide ou un tag.

--with-patch=package=file

Add file to the list of patches applied to package, where package is a spec such as python@3.8 or glibc. file must contain a patch; it is applied with the flags specified in the origin of package (voir référence des origines), which by default includes -p1 (voir patch Directories dans Comparing and Merging Files).

As an example, the command below rebuilds Coreutils with the GNU C Library (glibc) patched with the given patch:

guix build coreutils --with-patch=glibc=./glibc-frob.patch

In this example, glibc itself as well as everything that leads to Coreutils in the dependency graph is rebuilt.

--without-tests=paquet

Construire paquet sans lancer la suite de tests. Celà peut être utile dans les situations où vous voulez éviter la longue série de tests d’un paquet intermédiaire, ou si une suite de tests de paquet échoue dans un mode non déterministe. Il doit être utilisé avec précaution car l’exécution de la suite de tests est un bon moyen de s’assurer qu’un paquet fonctionne comme prévu.

L’arrêt des tests conduit à un autre élément du dépôt. Par conséquent, lorsque vous utilisez cette option, tout ce qui dépend de paquet doit être reconstruit, comme dans cet exemple :

guix install --without-tests=python python-notebook

La commande ci-dessus installe python-notebook par dessus python, construit sans exécuter sa suite de tests. Pour ce faire, elle reconstruit également tout ce qui dépend de python, y compris python-notebook lui-même.

En interne, --without-tests repose sur le changement de l’option #:tests? de la phase check d’un paquet (voir Systèmes de construction). Notez que certains paquets utilisent une phase check personnalisée qui ne respecte pas le paramètre #:tests? #f. Par conséquent, --without-tests n’a aucun effet sur ces paquets.

Vous vous demandez comme faire la même chose dans du code Scheme, par exemple dans votre manifeste, ou comme écrire votre propre transformation de paquets ? Voir Définition de variantes de paquets, pour un aperçu des interfaces de programmation disponibles.


Suivant: , Précédent: , Monter: Invoquer guix build   [Table des matières][Index]