Suivant: Référence de origin
, Monter: Définition des paquets [Table des matières][Index]
package
Cette section résume toutes les options disponibles dans les déclarations
package
(voir Définition des paquets).
C’est le type de donnée représentant une recette de paquets.
name
Le nom du paquet, comme une chaîne de caractères.
version
La version du paquet, comme une chaine de caractères. Voir Numéros de version, pour un guide.
source
Un objet qui indique comment le code source du paquet devrait être
récupéré. La plupart du temps, c’est un objet origin
qui indique un
fichier récupéré depuis internet (voir Référence de origin
). Il peut aussi
s’agir de tout autre objet « simili-fichier » comme un local-file
qui
indique un fichier du système de fichier local (voir local-file
).
build-system
Le système de construction qui devrait être utilisé pour construire le paquet (voir Systèmes de construction).
arguments
(par défaut : '()
)Les arguments à passer au système de construction (voir Systèmes de construction). C’est une liste qui contient typiquement une séquence de paires de clefs-valeurs, comme dans cet exemple :
(package
(name "exemple")
;; plusieurs champs omis
(arguments
(list #:tests? #f ;passer les tests
#:make-flags #~'("VERBOSE=1") ;passer les arguments à « make »
#:configure-flags #~'("--enable-frobbing"))))
L’ensemble exact des mots-clés pris en charge dépend du système de
construction (voir Systèmes de construction), mais vous trouverez qu’ils prennent
presque tous en compte #:configure-flags
, #:make-flags
,
#:tests?
et #:phases
. Le mot-clé #:phases
en
particulier vous permet de modifier l’ensemble des phases de construction
pour votre paquet (voir Phases de construction).
inputs
(par défaut : '()
) ¶native-inputs
(par défaut : '()
)propagated-inputs
(par défaut : '()
)Ces champs listent les dépendances du paquet. Chacune de ces listes est soit un paquet, une origine ou un autre « objet simili-fichier » (voir G-Expressions) ; pour spécifier la sortie de cet objet simili-fichier à utiliser, passez une liste à deux éléments où le second élément est la sortie (voir Des paquets avec plusieurs résultats, pour plus d’informations sur les sorties des paquets). Par exemple, la liste suivante spécifie trois entrées :
(list libffi libunistring `(,glib "bin")) ;la sortie « bin » de GLib
Dans l’exemple au-dessus, on utilise la sortie "out"
de libffi
et de libunistring
.
Notes de compatibilité : Jusqu’à la version 1.3.0, les listes d’entrées étaient des listes de tuples, où chaque tuple a une étiquette pour une entrée (une chaîne de caractères) comme premier élément, un paquet, une origine ou une dérivation comme deuxième élément et éventuellement le nom d’une sortie à utiliser qui est
"out"
par défaut. Par exemple, la liste ci-dessous est équivalente à celle au-dessus, mais utilise l’ancien style d’entrées :;; Ancien style d'entrées (obsolète) `(("libffi" ,libffi) ("libunistring" ,libunistring) ("glib:bin" ,glib "bin")) ;la sortie "bin" de GlibCe style est maintenant obsolète ; il est toujours pris en charge mais la prise en charge sera supprimée dans une future version. Vous ne devriez pas l’utiliser pour de nouvelles définitions de paquets. Voir Invoquer
guix style
, pour apprendre à migrer vers le nouveau style.
La distinction entre native-inputs
et inputs
est nécessaire
lorsqu’on considère la compilation croisée. Lors d’une compilation croisée,
les dépendances listées dans inputs
sont construites pour
l’architecture cible ; inversement, les dépendances listées dans
native-inputs
sont construites pour l’architecture de la machine de
construction.
native-inputs
est typiquement utilisé pour lister les outils requis à
la construction mais pas à l’exécution, comme Autoconf, Automake,
pkg-config, Gettext ou Bison. guix lint
peut rapporter des
erreurs de ce type (voir Invoquer guix lint
).
Enfin, propagated-inputs
est similaire à inputs
, mais les
paquets spécifiés seront automatiquement installés sur les profils
(voir le rôle des profils dans Guix) à côté du paquet auquel
ils appartiennent (voir guix
package
, pour savoir comment guix package
traite les entrées
propagées).
Par exemple, cela est nécessaire lors de l’empaquetage d’une bibliothèque
C/C++ qui a besoin des en-têtes d’une autre bibliothèque pour se compiler,
ou lorsqu’un fichier pkg-config fait référence à un autre via son champ
Requires
.
Un autre exemple où le propagated-inputs
est utile, c’est pour les
langues qui ne disposent pas de la possibilité d’enregistrer le chemin de
recherche à l’exécution comme le RUNPATH
des fichiers ELF ; cela
inclut Guile, Python, Perl, et plus encore. Lors de l’empaquetage de
bibliothèques écrites dans ces langages, assurez-vous qu’elles peuvent
trouver le code de bibliothèque dont elles dépendent au moment de
l’exécution en listant les dépendances d’exécution dans
propagated-inputs
plutôt que inputs
.
outputs
(par défaut : '("out")
)La liste des noms de sorties du paquet. Voir Des paquets avec plusieurs résultats, pour des exemples typiques d’utilisation de sorties supplémentaires.
native-search-paths
(par défaut : '()
)search-paths
(par défaut : '()
)Une liste d’objets search-path-specification
décrivant les variables
d’environnement de recherche de chemins que ce paquet prend en
compte. Voir Chemins de recherche, pour plus de détails sur les spécifications de
chemins de recherche.
Comme pour les entrées, la distinction entre native-search-paths
et
search-paths
n’est importante que pour la compilation croisée. Lors
d’une compilation croisée, native-search-paths
ne s’applique qu’aux
entrées natives alors que search-paths
ne s’applique qu’aux entrées
hôtes.
Les paquets comme les compilateurs croisées font attention aux entrées de la
cible — par exemple notre compilateur GCC croisé (modifié) a
CROSS_C_INCLUDE_PATH
dans search-paths
, ce qui lui permet de
trouver les fichiers .h du système cible et pas ceux des
entrées natives. Pour la plupart des paquets cependant, seul
native-search-paths
a du sens.
replacement
(par défaut : #f
)Ce champ doit être soit #f
soit un objet de paquet qui sera utilisé
comme remplaçant de ce paquet. Voir grafts, pour
plus de détails.
synopsis
Une description sur une ligne du paquet.
description
Une description plus détaillée du paquet, en tant que chaine au format Texinfo.
license
¶La licence du paquet ; une valeur tirée de (guix licenses)
ou une
liste de ces valeurs.
home-page
L’URL de la page d’accueil du paquet, en tant que chaîne de caractères.
supported-systems
(par défaut : %supported-systems
)La liste des systèmes supportés par le paquet, comme des chaînes de
caractères de la forme architecture-noyau
, par exemple
"x86_64-linux"
.
location
(par défaut : emplacement de la source de la forme package
)L’emplacement de la source du paquet. C’est utile de le remplacer lorsqu’on hérite d’un autre paquet, auquel cas ce champ n’est pas automatiquement corrigé.
Lorsque vous l’utilisez dans la portée lexicale du champ d’une définition de paquet, cet identifiant est résolu comme étant le paquet définit.
L’exemple ci-dessous montre l’ajout d’un paquet comme entrée native de lui-même pour la compilation croisée :
(package
(name "guile")
;; ...
;; Lors de la compilation croisée, Guile par exemple dépend
;; d'une version native de lui-même. On l'ajoute ici.
(native-inputs (if (%current-target-system)
(list this-package)
'())))
C’est une erreur que de se référer à this-package
en dehors de la
définition d’un paquet.
Les procédures auxiliaires suivantes vous aideront à utiliser les entrées des paquets.
Cherche name dans les entrées de package (ou les entrées
natives, propagées ou directes). Renvoie l’entrée si elle la trouve, et
#f
sinon.
name est le nom d’un paquet de dépendance. Voici comment vous pouvez l’utiliser :
(use-modules (guix packages) (gnu packages base)) (lookup-package-direct-input coreutils "gmp") ⇒ #<package gmp@6.2.1 …>
Dans cet exemple, on obtient le paquet gmp
qui fait partie des
entrées directes de coreutils
.
Parfois vous voudrez obtenir la liste des entrées requises pour
développer un paquet — toutes les entrées visibles quand le paquet
est compilé. C’est ce que la procédure package-development-inputs
renvoie.
Renvoie la liste des entrées requises par package pour le
développement sur system. Lorsque target est vrai, les entrées
renvoyées sont celles requises pour la compilation croisée de package
de system vers target, où target est un triplet comme
"aarch64-linux-gnu"
.
Remarquez que le résultat inclus à la fois les entrées explicites et
implicites — les entrées ajoutées automatiquement par le système de
construction (voir Systèmes de construction). Prenons le paquet hello
pour
illustrer :
(use-modules (gnu packages base) (guix packages)) hello ⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790> (package-direct-inputs hello) ⇒ () (package-development-inputs hello) ⇒ (("source" …) ("tar" #<package tar@1.32 …>) …)
Dans cet exemple, package-direct-inputs
renvoie la liste vide, parce
que hello
n’a pas de dépendance explicite. À l’inverse,
package-development-inputs
inclut les entrées implicites ajoutées par
gnu-build-system
qui sont requises pour construire hello
:
tar, gzip, GCC, libc, Bash et d’autres. Pour les visualiser, guix
graph hello
montrerait les entrées explicites, alors que guix
graph -t bag hello
inclurait les entrées implicites (voir Invoque guix graph
).
Comme les paquets sont des objets Scheme réguliers qui capturent un graphe de dépendance complet et les procédures de construction associées, il est souvent utile d’écrire des procédures qui prennent un paquet et renvoient une version modifiée de celui-ci en fonction de certains paramètres. En voici quelques exemples.
Renvoie une variante de package qui utilise toolchain au lieu de
la chaîne d’outils GNU C/C++ par défaut. toolchain doit être une
liste d’entrées (tuples label/package) fournissant une fonctionnalité
équivalente, comme le paquet gcc-toolchain
.
L’exemple ci-dessous renvoie une variante du paquet hello
construit
avec GCC 10.x et le reste de la chaîne d’outils GNU (Binutils et la
bibliothèque C GNU) au lieu de la chaîne d’outils par défaut :
(let ((toolchain (specification->package "gcc-toolchain@10")))
(package-with-c-toolchain hello `(("toolchain" ,toolchain))))
La chaîne d’outils de construction fait partie des entrées implicites des paquets— elle n’est généralement pas listée comme faisant partie des différents champs "entrées" et est à la place récupérée par le système de construction. Par conséquent, cette procédure fonctionne en modifiant le système de compilation de paquet de sorte qu’il utilise toolchain au lieu des valeurs par défaut. Systèmes de construction, pour en savoir plus sur les systèmes de construction.
Suivant: Référence de origin
, Monter: Définition des paquets [Table des matières][Index]