Nächste: „origin“-Referenz, Nach oben: Pakete definieren [Inhalt][Index]
package
-ReferenzDieser Abschnitt fasst alle in package
-Deklarationen zur Verfügung
stehenden Optionen zusammen (siehe Pakete definieren).
Dieser Datentyp steht für ein Paketrezept.
name
Der Name des Pakets als Zeichenkette.
version
Die Version des Pakets als Zeichenkette.
source
Ein Objekt, das beschreibt, wie der Quellcode des Pakets bezogen werden
soll. Meistens ist es ein origin
-Objekt, welches für eine aus dem
Internet heruntergeladene Datei steht (siehe „origin“-Referenz). Es
kann aber auch ein beliebiges anderes „dateiähnliches“ Objekt sein, wie
z.B. ein local-file
, was eine Datei im lokalen Dateisystem
bezeichnet (siehe local-file
).
build-system
Das Erstellungssystem, mit dem das Paket erstellt werden soll (siehe Erstellungssysteme).
arguments
(Vorgabe: '()
)Die Argumente, die an das Erstellungssystem übergeben werden sollen. Dies ist eine Liste, typischerweise eine Reihe von Schlüssel-Wert-Paaren.
inputs
(Vorgabe: '()
)native-inputs
(Vorgabe: '()
)propagated-inputs
(Vorgabe: '()
)In diesen Feldern werden die Abhängigkeiten des Pakets aufgeführt. Jedes
dieser Felder enthält eine Liste von Tupeln, wobei jedes Tupel eine
Bezeichnung für die Eingabe (als Zeichenkette) als erstes Element, dann ein
„package“-, „origin“- oder „derivation“-Objekt (Paket, Ursprung oder
Ableitung) als zweites Element und optional die Benennung der davon zu
benutzenden Ausgabe umfasst; letztere hat als Vorgabewert "out"
(siehe Pakete mit mehreren Ausgaben. für mehr Informationen zu
Paketausgaben). Im folgenden Beispiel etwa werden drei Eingaben festgelegt:
`(("libffi" ,libffi) ("libunistring" ,libunistring) ("glib:bin" ,glib "bin")) ;Ausgabe "bin" von Glib
Die Unterscheidung zwischen native-inputs
und inputs
ist
wichtig, damit Cross-Kompilieren möglich ist. Beim Cross-Kompilieren werden
als inputs
aufgeführte Abhängigkeiten für die
Ziel-Prozessorarchitektur (target) erstellt, andersherum werden als
native-inputs
aufgeführte Abhängigkeiten für die Prozessorarchitektur
der erstellenden Maschine (build) erstellt.
native-inputs
listet typischerweise die Werkzeuge auf, die während
der Erstellung gebraucht werden, aber nicht zur Laufzeit des Programms
gebraucht werden. Beispiele sind Autoconf, Automake, pkg-config, Gettext
oder Bison. guix lint
kann melden, ob wahrscheinlich Fehler in der
Auflistung sind (siehe Aufruf von guix lint).
Schließlich ist propagated-inputs
ähnlich wie inputs
, aber die
angegebenen Pakete werden automatisch mit ins Profil installiert (siehe
die Rolle von Profilen in Guix), wenn das Paket installiert
wird, zu dem sie gehören (siehe guix package
für Informationen darüber, wie guix
package
mit propagierten Eingaben umgeht).
Dies ist zum Beispiel nötig, wenn Sie ein Paket für eine C-/C++-Bibliothek
schreiben, die Header-Dateien einer anderen Bibliothek braucht, um mit ihr
kompilieren zu können, oder wenn sich eine pkg-config-Datei auf eine andere
über ihren Requires
-Eintrag bezieht.
Noch ein Beispiel, wo propagated-inputs
nützlich ist, sind Sprachen,
die den Laufzeit-Suchpfad nicht zusammen mit dem Programm abspeichern
(nicht wie etwa im RUNPATH
bei ELF-Dateien), also Sprachen wie
Guile, Python, Perl und weitere. Wenn Sie ein Paket für eine in solchen
Sprachen geschriebene Bibliothek schreiben, dann sorgen Sie dafür, dass es
zur Laufzeit den von ihr benötigten Code finden kann, indem Sie ihre
Laufzeit-Abhängigkeiten in propagated-inputs
statt in inputs
aufführen.
outputs
(Vorgabe: '("out")
)Die Liste der Benennungen der Ausgaben des Pakets. Der Abschnitt Pakete mit mehreren Ausgaben. beschreibt übliche Nutzungen zusätzlicher Ausgaben.
native-search-paths
(Vorgabe: '()
)search-paths
(Vorgabe: '()
)Eine Liste von search-path-specification
-Objekten, die
Umgebungsvariable für von diesem Paket beachtete Suchpfade („search paths“)
beschreiben.
replacement
(Vorgabe: #f
)Dies muss entweder #f
oder ein package-Objekt sein, das als Ersatz
(replacement) dieses Pakets benutzt werden soll. Im Abschnitt zu
Veredelungen wird dies erklärt.
synopsis
Eine einzeilige Beschreibung des Pakets.
description
Eine ausführlichere Beschreibung des Pakets.
license
Die Lizenz des Pakets; benutzt werden kann ein Wert aus dem Modul
(guix licenses)
oder eine Liste solcher Werte.
home-page
Die URL, die die Homepage des Pakets angibt, als Zeichenkette.
supported-systems
(Vorgabe: %supported-systems
)Die Liste der vom Paket unterstützten Systeme als Zeichenketten der Form
Architektur-Kernel
, zum Beispiel "x86_64-linux"
.
location
(Vorgabe: die Stelle im Quellcode, wo die package
-Form steht)Wo im Quellcode das Paket definiert wurde. Es ist sinnvoll, dieses Feld manuell zuzuweisen, wenn das Paket von einem anderen Paket erbt, weil dann dieses Feld nicht automatisch berichtigt wird.
Wenn dies im lexikalischen Geltungsbereich der Definition eines Feldes im Paket steht, bezieht sich dieser Bezeichner auf das Paket, das gerade definiert wird.
Das folgende Beispiel zeigt, wie man ein Paket als native Eingabe von sich selbst beim Cross-Kompilieren deklariert:
(package
(name "guile")
;; …
;; Wenn es cross-kompiliert wird, hängt zum Beispiel
;; Guile von einer nativen Version von sich selbst ab.
;; Wir fügen sie hier hinzu.
(native-inputs (if (%current-target-system)
`(("self" ,this-package))
'())))
Es ist ein Fehler, außerhalb einer Paketdefinition auf this-package
zu verweisen.
Weil Pakete herkömmliche Scheme-Objekte sind, die einen vollständigen Abhängigkeitsgraphen und die zugehörigen Erstellungsprozeduren umfassen, bietet es sich oftmals an, Prozeduren zu schreiben, die ein Paket entgegennehmen und in Abhängigkeit bestimmter Parameter eine abgeänderte Fassung desselben zurückliefern. Es folgen einige Beispiele.
Liefert eine Variante des Pakets, die die angegebene Toolchain
anstelle der vorgegebenen GNU-C/C++-Toolchain benutzt. Als Toolchain
muss eine Liste von Eingaben (als Tupel aus Bezeichnung und bezeichnetem
Paket) angegeben werden, die eine gleichartige Funktion erfüllen, wie zum
Beispiel das Paket gcc-toolchain
.
Das folgende Beispiel liefert eine Variante des Pakets hello
, die mit
GCC 10.x und den übrigen Komponenten der GNU-Toolchain (Binutils und
GNU-C-Bibliothek) erstellt wurde statt mit der vorgegebenen Toolchain:
(let ((toolchain (specification->package "gcc-toolchain@10")))
(package-with-c-toolchain hello `(("toolchain" ,toolchain))))
Die Erstellungs-Toolchain gehört zu den impliziten Eingaben von Paketen — sie wird normalerweise nicht ausdrücklich unter den verschiedenen „inputs“-Feldern mit verschiedenen Arten von Eingaben aufgeführt, stattdessen kommt sie über das Erstellungssystem dazu. Daher funktioniert diese Prozedur intern so, dass sie das Erstellungssystem des Pakets verändert, damit es die ausgewählte Toolchain statt der vorgegebenen benutzt. Siehe Erstellungssysteme für weitere Informationen zu Erstellungssystemen.
Nächste: „origin“-Referenz, Nach oben: Pakete definieren [Inhalt][Index]