Zusätzliche Erstellungsoptionen (Referenzhandbuch zu GNU Guix)

10.1.3 Zusätzliche Erstellungsoptionen

Die unten aufgeführten Befehlszeilenoptionen funktionieren nur mit guix build.

--quiet

-q

Schweigend erstellen, ohne das Erstellungsprotokoll anzuzeigen – dies ist äquivalent zu --verbosity=0. Nach Abschluss der Erstellung ist das Protokoll in /var (oder einem entsprechenden Ort) einsehbar und kann jederzeit mit der Befehlszeilenoption --log-file gefunden werden.

--file=Datei

-f Datei

Das Paket, die Ableitung oder das dateiähnliche Objekt erstellen, zu dem der Code in der Datei ausgewertet wird (siehe dateiartige Objekte).

Zum Beispiel könnte in der Datei so eine Paketdefinition stehen (siehe Pakete definieren):

(use-modules (guix)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (build-system gnu-build-system)
  (synopsis "Hello, GNU world: An example GNU package")
  (description "Guess what GNU Hello prints!")
  (home-page "http://www.gnu.org/software/hello/")
  (license gpl3+))

Die Datei darf auch eine JSON-Darstellung von einer oder mehreren Paketdefinitionen sein. Wenn wir guix build -f auf einer hello.json-Datei mit dem folgenden Inhalt ausführen würden, würden die Pakete myhello und greeter erstellt werden:

[
  {
    "name": "myhello",
    "version": "2.10",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "tests?": false
    }
    "home-page": "https://www.gnu.org/software/hello/",
    "synopsis": "Hello, GNU world: An example GNU package",
    "description": "GNU Hello prints a greeting.",
    "license": "GPL-3.0+",
    "native-inputs": ["gettext"]
  },
  {
    "name": "greeter",
    "version": "1.0",
    "source": "https://example.com/greeter-1.0.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "test-target": "foo",
      "parallel-build?": false,
    },
    "home-page": "https://example.com/",
    "synopsis": "Greeter using GNU Hello",
    "description": "This is a wrapper around GNU Hello.",
    "license": "GPL-3.0+",
    "inputs": ["myhello", "hello"]
  }
]

--manifest=Manifest

-m Manifest

Alle Pakete erstellen, die im angegebenen Manifest stehen (siehe --manifest).

--expression=Ausdruck

-e Ausdruck

Das Paket oder die Ableitung erstellen, zu der der Ausdruck ausgewertet wird.

Zum Beispiel kann der Ausdruck (@ (gnu packages guile) guile-1.8) sein, was diese bestimmte Variante der Version 1.8 von Guile eindeutig bezeichnet.

Alternativ kann der Ausdruck ein G-Ausdruck sein. In diesem Fall wird er als Erstellungsprogramm an gexp->derivation übergeben (siehe G-Ausdrücke).

Zudem kann der Ausdruck eine monadische Prozedur mit null Argumenten bezeichnen (siehe Die Store-Monade). Die Prozedur muss eine Ableitung als monadischen Wert zurückliefern, die dann durch run-with-store laufen gelassen wird.

--source

-S

Die Quellcode-Ableitung der Pakete statt die Pakete selbst erstellen.

Zum Beispiel liefert guix build -S gcc etwas in der Art von /gnu/store/…-gcc-4.7.2.tar.bz2, also den Tarball mit dem GCC-Quellcode.

Der gelieferte Quell-Tarball ist das Ergebnis davon, alle Patches und Code-Schnipsel aufzuspielen, die im origin-Objekt des Pakets festgelegt wurden (siehe Pakete definieren).

Wie andere Arten von Ableitung kann auch das Ergebnis einer Quellcode-Ableitung mit der Befehlszeilenoption --check geprüft werden (siehe build-check). Das ist nützlich, um zu überprüfen, ob ein (vielleicht bereits erstellter oder substituierter, also zwischengespeicherter) Paketquellcode zu ihrer deklarierten Hash-Prüfsumme passt.

Beachten Sie, dass guix build -S nur für die angegebenen Pakete den Quellcode herunterlädt. Dazu gehört nicht der Quellcode statisch gebundener Abhängigkeiten und der Quellcode alleine reicht nicht aus, um die Pakete zu reproduzieren.

--sources

Den Quellcode für Paket-oder-Ableitung und alle Abhängigkeiten davon rekursiv herunterladen und zurückliefern. Dies ist eine praktische Methode, eine lokale Kopie des gesamten Quellcodes zu beziehen, der nötig ist, um die Pakete zu erstellen, damit Sie diese später auch ohne Netzwerkzugang erstellen lassen können. Es handelt sich um eine Erweiterung der Befehlszeilenoption --source, die jeden der folgenden Argumentwerte akzeptiert:

package

Mit diesem Wert verhält sich die Befehlszeilenoption --sources auf genau die gleiche Weise wie die Befehlszeilenoption --source.

all

Erstellt die Quellcode-Ableitungen aller Pakete einschließlich allen Quellcodes, der als Teil der Eingaben im inputs-Feld aufgelistet ist. Dies ist der vorgegebene Wert, wenn sonst keiner angegeben wird.

$ guix build --sources tzdata
Folgende Ableitungen werden erstellt:
   /gnu/store/…-tzdata2015b.tar.gz.drv
   /gnu/store/…-tzcode2015b.tar.gz.drv

transitive

Die Quellcode-Ableitungen aller Pakete sowie aller transitiven Eingaben der Pakete erstellen. Damit kann z.B. Paket-Quellcode vorab heruntergeladen und später offline erstellt werden.

$ guix build --sources=transitive tzdata
Folgende Ableitungen werden erstellt:
   /gnu/store/…-tzcode2015b.tar.gz.drv
   /gnu/store/…-findutils-4.4.2.tar.xz.drv
   /gnu/store/…-grep-2.21.tar.xz.drv
   /gnu/store/…-coreutils-8.23.tar.xz.drv
   /gnu/store/…-make-4.1.tar.xz.drv
   /gnu/store/…-bash-4.3.tar.xz.drv
…

--system=System

-s System

Versuchen, für das angegebene System – z.B. i686-linux – statt für denselben Systemtyp wie auf dem Wirtssystem zu erstellen. Beim Befehl guix build können Sie diese Befehlszeilenoption mehrmals wiederholen, wodurch für jedes angegebene System eine Erstellung durchgeführt wird; andere Befehle ignorieren überzählige -s-Befehlszeilenoptionen.

Anmerkung: Die Befehlszeilenoption --system dient der nativen Kompilierung (nicht zu verwechseln mit Cross-Kompilierung). Siehe --target unten für Informationen zur Cross-Kompilierung.

Ein Beispiel sind Linux-basierte Systeme, die verschiedene Persönlichkeiten emulieren können. Zum Beispiel können Sie --system=i686-linux auf einem x86_64-linux-System oder --system=armhf-linux auf einem aarch64-linux-System angeben, um Pakete in einer vollständigen 32-Bit-Umgebung zu erstellen.

Anmerkung: Das Erstellen für ein armhf-linux-System ist ungeprüft auf allen aarch64-linux-Maschinen aktiviert, obwohl bestimmte aarch64-Chipsätze diese Funktionalität nicht unterstützen, darunter auch ThunderX.

Ebenso können Sie, wenn transparente Emulation mit QEMU und binfmt_misc aktiviert sind (siehe qemu-binfmt-service-type), für jedes System Erstellungen durchführen, für das ein QEMU-binfmt_misc-Handler installiert ist.

Erstellungen für ein anderes System, das nicht dem System der Maschine, die Sie benutzen, entspricht, können auch auf eine entfernte Maschine mit der richtigen Architektur ausgelagert werden. Siehe Nutzung der Auslagerungsfunktionalität für mehr Informationen über das Auslagern.

--target=Tripel ¶

Lässt für das angegebene Tripel cross-erstellen. Dieses muss ein gültiges GNU-Tripel wie z.B. "aarch64-linux-gnu" sein (siehe GNU-Konfigurationstripel in Autoconf).

--list-systems

Listet alle unterstützten Systeme auf, die als Argument an --system gegeben werden können.

--list-targets

Listet alle unterstützten Ziele auf, die als Argument an --target gegeben werden können.

--check ¶

Paket-oder-Ableitung erneut erstellen, wenn diese bereits im Store verfügbar ist, und einen Fehler melden, wenn die Erstellungsergebnisse nicht Bit für Bit identisch sind.

Mit diesem Mechanismus können Sie überprüfen, ob zuvor installierte Substitute unverfälscht sind (siehe Substitute) oder auch ob das Erstellungsergebnis eines Pakets deterministisch ist. Siehe guix challenge aufrufen für mehr Hintergrundinformationen und Werkzeuge.

Wenn dies zusammen mit --keep-failed benutzt wird, bleiben die sich unterscheidenden Ausgaben im Store unter dem Namen /gnu/store/…-check. Dadurch können Unterschiede zwischen den beiden Ergebnissen leicht erkannt werden.

--repair ¶

Versuchen, die angegebenen Store-Objekte zu reparieren, wenn sie beschädigt sind, indem sie neu heruntergeladen oder neu erstellt werden.

Diese Operation ist nicht atomar und nur der Administratornutzer root kann sie verwenden.

--derivations

-d

Liefert die Ableitungspfade und nicht die Ausgabepfade für die angegebenen Pakete.

--root=Datei ¶

-r Datei

Die Datei zu einer symbolischen Verknüpfung auf das Ergebnis machen und als Müllsammlerwurzel registrieren.

Dadurch wird das Ergebnis dieses Aufrufs von guix build vor dem Müllsammler geschützt, bis die Datei gelöscht wird. Wird diese Befehlszeilenoption nicht angegeben, können Erstellungsergebnisse vom Müllsammler geholt werden, sobald die Erstellung abgeschlossen ist. Siehe guix gc aufrufen für mehr Informationen zu Müllsammlerwurzeln.

--log-file ¶

Liefert die Dateinamen oder URLs der Erstellungsprotokolle für das angegebene Paket-oder-Ableitung oder meldet einen Fehler, falls Protokolldateien fehlen.

Dies funktioniert, egal wie die Pakete oder Ableitungen angegeben werden. Zum Beispiel sind folgende Aufrufe alle äquivalent:

guix build --log-file $(guix build -d guile)
guix build --log-file $(guix build guile)
guix build --log-file guile
guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'

Wenn ein Protokoll lokal nicht verfügbar ist und sofern --no-substitutes nicht übergeben wurde, sucht der Befehl nach einem entsprechenden Protokoll auf einem der Substitutserver (die mit --substitute-urls angegeben werden können).

Stellen Sie sich zum Beispiel vor, sie wollten das Erstellungsprotokoll von GDB auf einem aarch64-System sehen, benutzen aber selbst eine x86_64-Maschine:

$ guix build --log-file gdb -s aarch64-linux
https://ci.guix.gnu.org/log/…-gdb-7.10

So haben Sie umsonst Zugriff auf eine riesige Bibliothek von Erstellungsprotokollen!