Nächste: Fehlschläge beim Erstellen untersuchen, Vorige: Paketumwandlungsoptionen, Nach oben: Aufruf von guix build
[Inhalt][Index]
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": "mirror://gnu/hello/hello-2.10.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.
--development
-D
Build the “development environment” (build dependencies) of the following package.
For example, the following command builds the inputs of hello
, but
not hello
itself, and also builds guile
:
guix build -D hello guile
Notice that -D (or --development) only applies to the
immediately following package on the command line. Under the hood, it uses
package->development-manifest
(siehe package->development-manifest
).
Anmerkung: The effect of combining --development with --target (for cross-compilation) may not be what you expect: it will cross-compile all the dependencies of the given package when it is built natively.
--dependents[=depth]
-P [depth]
Build the dependents of the following package. By default, build all the direct and indirect dependents; when depth is provided, limit to dependents at that distance: 1 for direct dependents, 2 for dependents of dependents, and so on.
For example, the command below builds all the dependents of libgit2:
guix build --dependents libgit2
To build all the packages that directly depend on NumPy, run:
guix build -P1 python-numpy
The list of dependents is computed in the same way as with guix
refresh --list-dependent
(siehe guix refresh
aufrufen).
--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 allenaarch64-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)'
If a log is unavailable locally, and unless --no-substitutes is passed, the command looks for a corresponding log on one of the substitute servers.
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://bordeaux.guix.gnu.org/log/…-gdb-7.10
So haben Sie umsonst Zugriff auf eine riesige Bibliothek von Erstellungsprotokollen!
Nächste: Fehlschläge beim Erstellen untersuchen, Vorige: Paketumwandlungsoptionen, Nach oben: Aufruf von guix build
[Inhalt][Index]