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. Siehe Versionsnummern, wo erklärt wird, worauf Sie achten müssen.
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 (siehe Erstellungssysteme). Dies ist eine Liste, typischerweise eine Reihe von Schlüssel-Wert-Paaren wie in diesem Beispiel:
(package
(name "beispiel")
;; hier würden noch ein paar Felder stehen
(arguments
(list #:tests? #f ;Tests überspringen
#:make-flags #~'("VERBOSE=1") ;Optionen für 'make'
#:configure-flags #~'("--enable-frobbing"))))
Welche Schlüsselwortargumente genau unterstützt werden, hängt vom jeweiligen
Erstellungssystem ab (siehe Erstellungssysteme), doch werden Sie
feststellen, dass fast alle #:configure-flags
, #:make-flags
,
#:tests?
und #:phases
berücksichtigen. Insbesondere können Sie
mit dem Schlüsselwort #:phases
den Satz von Erstellungsphasen, der
für Ihr Paket zum Einsatz kommt, ändern (siehe Erstellungsphasen).
inputs
(Vorgabe: '()
) ¶native-inputs
(Vorgabe: '()
)propagated-inputs
(Vorgabe: '()
)In diesen Feldern wird eine Liste der Abhängigkeiten des Pakets aufgeführt. Dabei ist jedes Listenelement ein „package“-, „origin“- oder sonstiges dateiartiges Objekt (siehe G-Ausdrücke). Um die zu benutzende Ausgabe zu benennen, übergeben Sie eine zweielementige Liste mit der Ausgabe als zweitem Element (siehe Pakete mit mehreren Ausgaben. für mehr Informationen zu Paketausgaben). Im folgenden Beispiel etwa werden drei Eingaben festgelegt:
(list libffi libunistring `(,glib "bin")) ;Ausgabe "bin" von GLib
Im obigen Beispiel wird die Ausgabe "out"
für libffi
und
libunistring
benutzt.
Anmerkung zur Kompatibilität: Bis Version 1.3.0 waren Eingabelisten noch Listen 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 umfasste; letztere hatte als Vorgabewert
"out"
. Im folgenden Beispiel wird dasselbe wie oben angegeben, aber im alten Stil für Eingaben:;; Alter Eingabenstil (veraltet). `(("libffi" ,libffi) ("libunistring" ,libunistring) ("glib:bin" ,glib "bin")) ;Ausgabe "bin" von GLibDieser Stil gilt als veraltet. Er wird bislang unterstützt, aber er wird in einer zukünftigen Version entfernt werden. Man sollte ihn nicht für neue Paketdefinitionen gebrauchen. Siehe
guix style
aufrufen für eine Erklärung, wie Sie zum neuen Stil migrieren.
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 guix lint
aufrufen).
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. Siehe Suchpfade, wenn Sie mehr über
Suchpfadspezifikationen erfahren möchten.
Wie auch bei Eingaben wird zwischen native-search-paths
und
search-paths
nur dann ein Unterschied gemacht, wenn Sie
cross-kompilieren. Beim Cross-Kompilieren bezieht sich
native-search-paths
ausschließlich auf native Eingaben, wohingegen
sich die search-paths
ausschließlich auf Eingaben für den „Host“
genannten Rechner beziehen.
Für Pakete wie z.B. Cross-Compiler sind die Ziel-Eingaben wichtig, z.B.
hat unser (angepasster) GCC-Cross-Compiler einen Eintrag für
CROSS_C_INCLUDE_PATH
in search-paths
, damit er
.h-Dateien für das Zielsystem auswählt und nicht die aus
nativen Eingaben. Für die meisten Pakete ist aber einzig
native-search-paths
von Bedeutung.
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, als eine Zeichenkette in Texinfo-Syntax.
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)
(list this-package)
'())))
Es ist ein Fehler, außerhalb einer Paketdefinition auf this-package
zu verweisen.
Die folgenden Hilfsprozeduren sind für den Umgang mit Paketeingaben gedacht.
Name unter den (nativen, propagierten, direkten) Eingaben von
Paket suchen und die Eingabe zurückliefern, wenn sie gefunden wird,
ansonsten #f
.
Name ist der Name eines Pakets, von dem eine Abhängigkeit besteht. So benutzen Sie die Prozeduren:
(use-modules (guix packages) (gnu packages base)) (lookup-package-direct-input coreutils "gmp") ⇒ #<package gmp@6.2.1 …>
In diesem Beispiel erhalten wir das gmp
-Paket, das zu den direkten
Eingaben von coreutils
gehört.
Manchmal werden Sie die Liste der zur Entwicklung an einem Paket nötigen
Eingaben brauchen, d.h. alle Eingaben, die beim Kompilieren des Pakets
sichtbar gemacht werden. Diese Liste wird von der Prozedur
package-development-inputs
geliefert.
Paket zu Entwicklungszwecken für System braucht. Wenn
target wahr ist, muss dafür ein Ziel wie das GNU-Tripel
"aarch64-linux-gnu"
übergeben werden, damit die Eingaben zum
Cross-Kompilieren von Paket zurückgeliefert werden.
Beachten Sie, dass dazu sowohl explizite als auch implizite Eingaben
gehören. Mit impliziten Eingaben meinen wir solche, die vom
Erstellungssystem automatisch hinzugefügt werden (siehe Erstellungssysteme). Nehmen wir das Paket hello
zur Illustration:
(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 …>) …)
Für dieses Beispiel liefert package-direct-inputs
die leere Liste
zurück, weil hello
keinerlei explizite Abhängigkeiten hat. Zu
package-development-inputs
gehören auch durch gnu-build-system
implizit hinzugefügte Eingaben, die für die Erstellung von hello
gebraucht werden, nämlich tar, gzip, GCC, libc, Bash und weitere. Wenn Sie
sich das anschauen wollen, zeigt Ihnen guix graph hello
die
expliziten Eingaben, dagegen zeigt guix graph -t bag hello
auch
die impliziten Eingaben (siehe guix graph
aufrufen).
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]