Nächste: , Nach oben: Pakete definieren   [Inhalt][Index]


6.2.1 package-Referenz

Dieser Abschnitt fasst alle in package-Deklarationen zur Verfügung stehenden Optionen zusammen (siehe Pakete definieren).

Datentyp: package

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, 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 eine C-/C++-Bibliothek 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. Damit auch in solchen Sprachen geschriebene Bibliotheken zur Laufzeit den von ihnen benötigten Code finden können, müssen deren Laufzeit-Abhängigkeiten in propagated-inputs statt in inputs aufgeführt werden.

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 grafts 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.

Scheme-Syntax: this-package

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.


Nächste: , Nach oben: Pakete definieren   [Inhalt][Index]