per page, with , order by , clip by
Results of 0 - 1 of about 0 (0.001 sec.)
Systèmes de construction (Manuel de référence de GNU Guix)
@digest: e8c5b613eec6b98bec0078d5e88f979b
@id: 74211
@mdate: 2019-05-19T21:18:25Z
@size: 52124
@type: text/html
content-type: text/html; charset=utf-8
description: Systèmes de construction (Manuel de référence de GNU Guix)
distribution: global
generator: makeinfo
keywords: Systèmes de construction (Manuel de référence de GNU Guix)
resource-type: document
#keywords: exportee (166939), drapeaux (66133), parametre (54564), paquets (38502), paquet (37925), implemente (35168), construction (34415), specifie (23610), clojure (21264), entrees (19539), fichiers (18881), utilise (15823), systeme (15637), bibliotheques (15619), repertoire (15195), installe (14805), repertoires (14261), ocaml (12431), phases (12237), binaires (11521), construire (11199), defaut (11018), scons (11002), lancer (10832), parametres (10338), lance (8635), ajoute (8392), systemes (8365), etre (8364), peuvent (8233), schemas (8123), fichier (8051)
Suivant: Le dépôt , Précédent: Définition des paquets , Monter: Interface de programmation [ Table des matières ][ Index ] 6.3 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 ). 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 Scheme : 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, notamment 15 : unpack Décompresse l'archive des sources et se déplace dans l'arborescence des sources fraîchement extraites. Si la source est en fait un répertoire, le copie dans l'arborescence de construction et entre dans ce répertoire. patch-source-shebangs Corrige les shebangs ( #! ) rencontrés dans les fichiers pour qu'ils se réfèrent aux bons noms de fichiers. Par exemple, elle change #!/bin/sh en #!/gnu/store/…-bash-4.3/bin/sh . configure Lance le script configure avec un certain nombre d'options par défaut, comme --prefix=/gnu/store/… , ainsi que les options spécifiées par l'argument #:configure-flags . build Lance make avec la liste des drapeaux spécifiés avec #:make-flags . Si l'argument #:parallel-build? est vrai (par défaut), construit avec make -j . check Lance make check , ou une autre cible spécifiée par #:test-target , à moins que #:tests? #f ne soit passé. Si l'argument #:parallel-tests? est vrai (par défaut), lance make check -j . install Lance make install avec les drapeaux listés dans #:make-flags . patch-shebangs Corrige les shebangs des fichiers exécutables installés. strip Nettoie les symboles de débogage dans les fichiers ELF (à moins que #:strip-binaries? ne soit faux), les copie dans la sortie debug lorsqu'elle est disponible (voir Installer les fichiers de débogage ). Le module du côté du constructeur (guix build gnu-build-system) définie %standard-phases comme la liste par défaut des phases de construction. %standard-phases est une liste de paires de symboles et de procédures, où la procédure implémente la phase en question. La liste des phases utilisées par un paquet particulier peut être modifiée avec le paramètre #:phases . Par exemple, en passant : #:phases (modify-phases %standard-phases (delete 'configure)) signifie que toutes les procédures décrites plus haut seront utilisées, sauf la phase configure . 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. 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 Scheme : 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 Scheme : 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 construction suppose que les paquets installent leur interface publique (les en-têtes) dans un sous-répertoire de « 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 Scheme : asdf-build-system/source Variable Scheme : asdf-build-system/sbcl Variable Scheme : 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 les paquets binaires, chaque système devrait être défini comme un paquet Guix. Si un paquet origine contient plusieurs systèmes, on peut créer des variantes du paquet pour construire tous les systèmes. Les paquets sources, qui utilisent asdf-build-system/source , peuvent contenir plusieurs systèmes. 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-symlinks 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 . Si le système n'est pas défini dans son propre fichier .asd du même nom, alors le paramètre #:asd-file devrait être utilisé pour spécifier dans quel fichier le système est défini. De plus, si le paquet défini un système pour ses tests dans un fichier séparé, il sera chargé avant que les tests ne soient lancés s'il est spécifié par le paramètre #:test-asd-file . S'il n'est pas spécifié, les fichiers <system>-tests.asd , <system>-test.asd , tests.asd et test.asd seront testés. 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, le paramètre #:asd-system-name peut être utilisé pour spécifier le nom du système. Variable Scheme : 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 . Dans sa phase configure , ce système de construction remplace les dépendances spécifiées dans le fichier Cargo.toml par les paquets Guix spécifiés en entrée. La phase install installe les binaires et installe aussi le code source et le fichier Cargo.toml . Variable Scheme : 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 Scheme : 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 Scheme : 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 Scheme : 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. Variable Scheme : 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 s'assure que les programmes dans bin/ sont capable de trouver les « schemas » GLib et les modules GTK+ . Ceci est fait en enveloppant les programmes dans des scripts de lancement qui initialisent correctement 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 Scheme : 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 Scheme : 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 Scheme : 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, le 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 Scheme : 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 dans bin/ , elle prend soin d'envelopper ces binaires pour que leur variable d'environnement 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 , comme le fait pip . Certains paquets ne sont pas compatibles avec setuptools (et pip), ainsi vous pouvez désactiver cela en mettant le paramètre #:use-setuptools à #f . Variable Scheme : 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 Scheme : r-build-system Cette variable est exportée par (guix build-system r) . Elle implémente la procédure de construction utilisée par les paquets R qui consiste à lancer à peine plus que R CMD INSTALL --library=/gnu/store/… dans un environnement où R_LIBS_SITE contient les chemins de toutes les entrées R. Les tests sont lancés après l'installation avec la fonction R tools::testInstalledPackage . Variable Scheme : 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ètres 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 Scheme : 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. 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. Variable Scheme : 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 développeurs Ruby quand ils 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 Scheme : 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 Scheme : 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. On peut passer des drapeaux supplémentaires à scons en les spécifiant avec le paramètre #:scons-flags . La version de python utilisée pour lancer SCons peut être spécifiée en sélectionnant le paquet SCons approprié avec le paramètre #:scons . Variable Scheme : 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 Scheme : 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 Scheme : 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 ). Elle 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é. Chaque paquet est installé dans son propre répertoire dans share/emacs/site-lisp/guix.d . Variable Scheme : 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 Scheme : 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. Le Meson par défaut est meson-for-build , qui est spécial parce qu'il ne nettoie pas le RUNPATH des binaires et les bibliothèques qu'il installe. 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 --build-type est toujours initialisé à plain à moins que quelque chose d'autre 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 ninja avec la cible spécifiée dans #:test-target , qui est "test" par défaut. 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-for-build 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 Scheme : 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 (dans la forme « arguments » d'un paquet utilisant le linux-module-build-system, utilisez la clef #:linux pour le spécifier). 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 Scheme : 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 ). Notes de bas de page (15) Regardez les modules (guix build gnu-build-system) pour plus de détails sur les phases de construction. Suivant: Le dépôt , Précédent: Définition des paquets , Monter: Interface de programmation [ Table des matières ][ Index ] ...
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/fr/html_node/Systemes-de-construction.html - [detail] - [similar]
PREV NEXT
Powered by Hyper Estraier 1.4.13, with 213336 documents and 1081300 words.