Nächste: , Vorige: , Nach oben: Aufruf von guix build   [Inhalt][Index]


9.1.2 Paketumwandlungsoptionen

Eine weitere Gruppe von Befehlszeilenoptionen, die guix build und auch guix package unterstützen, sind Paketumwandlungsoptionen. Diese Optionen ermöglichen es, Paketvarianten zu definieren — zum Beispiel können Pakete aus einem anderen Quellcode als normalerweise erstellt werden. Damit ist es leicht, angepasste Pakete schnell zu erstellen, ohne die vollständigen Definitionen von Paketvarianten einzutippen (siehe Pakete definieren).

Paketumwandlungsoptionen bleiben über Aktualisierungen hinweg erhalten: guix upgrade versucht, Umwandlungsoptionen, die vorher zur Erstellung des Profils benutzt wurden, auf die aktualisierten Pakete anzuwenden.

Im Folgenden finden Sie die verfügbaren Befehlszeilenoptionen. Die meisten Befehle unterstützen sie ebenso wie eine Option --help-transform, mit der all die verfügbaren Optionen und je eine Kurzbeschreibung dazu angezeigt werden. (Diese Optionen werden der Kürze wegen nicht in der Ausgabe von --help aufgeführt.)

--with-source=Quelle
--with-source=Paket=Quelle
--with-source=Paket@Version=Quelle

Den Paketquellcode für das Paket von der angegebenen Quelle holen und die Version als seine Versionsnummer verwenden. Die Quelle muss ein Dateiname oder eine URL sein wie bei guix download (siehe Aufruf von guix download).

Wird kein Paket angegeben, wird als Paketname derjenige auf der Befehlszeile angegebene Paketname angenommen, der zur Basis am Ende der Quelle passt — wenn z.B. als Quelle die Datei /src/guile-2.0.10.tar.gz angegeben wurde, entspricht das dem guile-Paket.

Ebenso wird, wenn keine Version angegeben wurde, die Version als Zeichenkette aus der Quelle abgeleitet; im vorherigen Beispiel wäre sie 2.0.10.

Mit dieser Option können Nutzer versuchen, eine andere Version ihres Pakets auszuprobieren, als die in der Distribution enthaltene Version. Folgendes Beispiel lädt ed-1.7.tar.gz von einem GNU-Spiegelserver herunter und benutzt es als Quelle für das ed-Paket:

guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz

Für Entwickler wird es einem durch --with-source leicht gemacht, „Release Candidates“, also Vorabversionen, zu testen:

guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz

… oder ein Checkout eines versionskontrollierten Repositorys in einer isolierten Umgebung zu erstellen:

$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=guix@1.0=./guix
--with-input=Paket=Ersatz

Abhängigkeiten vom Paket durch eine Abhängigkeit vom Ersatz-Paket ersetzen. Als Paket muss ein Paketname angegeben werden und als Ersatz eine Paketspezifikation wie guile oder guile@1.8.

Mit folgendem Befehl wird zum Beispiel Guix erstellt, aber statt der aktuellen stabilen Guile-Version hängt es von der alten Guile-Version guile@2.0 ab:

guix build --with-input=guile=guile@2.0 guix

Die Ersetzung ist rekursiv und umfassend. In diesem Beispiel würde nicht nur guix, sondern auch seine Abhängigkeit guile-json (was auch von guile abhängt) für guile@2.0 neu erstellt.

Implementiert wird das alles mit der Scheme-Prozedur package-input-rewriting (siehe package-input-rewriting).

--with-graft=Paket=Ersatz

Dies verhält sich ähnlich wie mit --with-input, aber mit dem wichtigen Unterschied, dass nicht die gesamte Abhängigkeitskette neu erstellt wird, sondern das Ersatz-Paket erstellt und die ursprünglichen Binärdateien, die auf das Paket verwiesen haben, damit veredelt werden. Im Abschnitt Sicherheitsaktualisierungen finden Sie weitere Informationen über Veredelungen.

Zum Beispiel veredelt folgender Befehl Wget und alle Abhängigkeiten davon mit der Version 3.5.4 von GnuTLS, indem Verweise auf die ursprünglich verwendete GnuTLS-Version ersetzt werden:

guix build --with-graft=gnutls=gnutls@3.5.4 wget

Das hat den Vorteil, dass es viel schneller geht, als alles neu zu erstellen. Die Sache hat aber einen Haken: Veredelung funktioniert nur, wenn das Paket und sein Ersatz miteinander streng kompatibel sind — zum Beispiel muss, wenn diese eine Programmbibliothek zur Verfügung stellen, deren Binärschnittstelle („Application Binary Interface“, kurz ABI) kompatibel sein. Wenn das Ersatz-Paket auf irgendeine Art inkompatibel mit dem Paket ist, könnte das Ergebnispaket unbrauchbar sein. Vorsicht ist also geboten!

--with-debug-info=Paket

Das Paket auf eine Weise erstellen, die Informationen zur Fehlersuche enthält, und von ihm abhängige Pakete damit veredeln. Das ist nützlich, wenn das Paket noch keine Fehlersuchinformationen als installierbare debug-Ausgabe enthält (siehe Dateien zur Fehlersuche installieren).

Als Beispiel nehmen wir an, Inkscape stürzt bei Ihnen ab und Sie möchten wissen, was dabei in GLib passiert. Die GLib-Bibliothek liegt tief im Abhängigkeitsgraphen von Inkscape und verfügt nicht über eine debug-Ausgabe; das erschwert die Fehlersuche. Glücklicherweise können Sie GLib mit Informationen zur Fehlersuche neu erstellen und an Inkscape anheften:

guix install inkscape --with-debug-info=glib

Nur GLib muss neu kompiliert werden, was in vernünftiger Zeit möglich ist. Siehe Dateien zur Fehlersuche installieren für mehr Informationen.

Anmerkung: Intern funktioniert diese Option, indem ‘#:strip-binaries? #f’ an das Erstellungssystem des betreffenden Pakets übergeben wird (siehe Erstellungssysteme). Die meisten Erstellungssysteme unterstützen diese Option, manche aber nicht. In diesem Fall wird ein Fehler gemeldet.

Auch wenn ein in C/C++ geschriebenes Paket ohne -g erstellt wird (was selten der Fall ist), werden Informationen zur Fehlersuche weiterhin fehlen, obwohl #:strip-binaries? auf falsch steht.

--with-c-toolchain=Paket=Toolchain

Mit dieser Befehlszeilenoption wird die Kompilierung des Pakets und aller davon abhängigen Objekte angepasst, so dass mit der Toolchain statt der vorgegebenen GNU-Toolchain für C/C++ erstellt wird.

Betrachten Sie dieses Beispiel:

guix build octave-cli \
  --with-c-toolchain=fftw=gcc-toolchain@10 \
  --with-c-toolchain=fftwf=gcc-toolchain@10

Mit dem obigen Befehl wird eine Variante der Pakete fftw und fftwf mit Version 10 der gcc-toolchain anstelle der vorgegebenen Toolchain erstellt, um damit anschließend eine diese benutzende Variante des GNU-Octave-Befehlszeilenprogramms zu erstellen. Auch GNU Octave selbst wird mit gcc-toolchain@10 erstellt.

Das zweite Beispiel bewirkt eine Erstellung der „Hardware Locality“-Bibliothek (hwloc) sowie ihrer abhängigen Objekte bis einschließlich intel-mpi-benchmarks mit dem Clang-C-Compiler:

guix build --with-c-toolchain=hwloc=clang-toolchain \
           intel-mpi-benchmarks

Anmerkung: Es kann vorkommen, dass die Anwendungsbinärschnittstellen („Application Binary Interfaces“, kurz ABIs) der Toolchains inkompatibel sind. Das tritt vor allem bei der C++-Standardbibliothek und Bibliotheken zur Laufzeitunterstützung wie denen von OpenMP auf. Indem alle abhängigen Objekte mit derselben Toolchain erstellt werden, minimiert --with-c-toolchain das Risiko, dass es zu Inkompatibilitäten kommt, aber es kann nicht ganz ausgeschlossen werden. Bedenken Sie, für welches Paket Sie dies benutzen.

--with-git-url=Paket=URL

Das Paket aus dem neuesten Commit im master-Branch des unter der URL befindlichen Git-Repositorys erstellen. Git-Submodule des Repositorys werden dabei rekursiv geladen.

Zum Beispiel erstellt der folgende Befehl die NumPy-Python-Bibliothek unter Verwendung des neuesten Commits von Python auf dessen „master“-Branch.

guix build python-numpy \
  --with-git-url=python=https://github.com/python/cpython

Diese Befehlszeilenoption kann auch mit --with-branch oder --with-commit kombiniert werden (siehe unten).

Da es den neuesten Commit auf dem verwendeten Branch benutzt, ändert sich das Ergebnis natürlich mit der Zeit. Nichtsdestoweniger ist es eine bequeme Möglichkeit, ganze Softwarestapel auf dem neuesten Commit von einem oder mehr Paketen aufbauen zu lassen. Es ist besonders nützlich im Kontext Kontinuierlicher Integration (englisch „Continuous Integration“, kurz CI).

Checkouts bleiben zwischengespeichert als ~/.cache/guix/checkouts, damit danach schneller auf dasselbe Repository zugegriffen werden kann. Eventuell möchten Sie das Verzeichnis ab und zu bereinigen, um Plattenplatz zu sparen.

--with-branch=Paket=Branch

Das Paket aus dem neuesten Commit auf dem Branch erstellen. Wenn das source-Feld des Pakets ein origin-Objekt mit der Methode git-fetch (siehe „origin“-Referenz) oder ein git-checkout-Objekt ist, wird die URL des Repositorys vom source-Feld genommen. Andernfalls müssen Sie die Befehlszeilenoption --with-git-url benutzen, um die URL des Git-Repositorys anzugeben.

Zum Beispiel wird mit dem folgenden Befehl guile-sqlite3 aus dem neuesten Commit seines master-Branches erstellt und anschließend guix (was von guile-sqlite3 abhängt) und cuirass (was von guix abhängt) unter Nutzung genau dieser guile-sqlite3-Erstellung erstellt:

guix build --with-branch=guile-sqlite3=master cuirass
--with-commit=Paket=Commit

Dies verhält sich ähnlich wie --with-branch, außer dass es den angegebenen Commit benutzt statt die Spitze eines angegebenen Branches. Als Commit muss ein gültiger SHA1-Bezeichner oder ein Tag für einen Git-Commit angegeben werden.

--without-tests=Paket

Das Paket erstellen, ohne seine Tests zu durchlaufen. Das erweist sich als nützlich, wenn Sie Testkataloge überspringen möchten, die viel Zeit in Anspruch nehmen, oder wenn der Testkatalog eines Pakets nichtdeterministisch fehlschlägt. Dies sollte mit Bedacht eingesetzt werden, denn das Ausführen des Testkatalogs sichert zu, dass ein Paket wie gewollt funktioniert.

Wenn die Tests abgeschaltet werden, ergibt sich ein anderes Store-Objekt. Dadurch muss, wenn diese Option benutzt wird, auch alles, was vom Paket abhängt, neu erstellt werden, wie Sie in diesem Beispiel sehen können:

guix install --without-tests=python python-notebook

Mit obigem Befehl wird python-notebook für ein python installiert, dessen Testkatalog nicht ausgeführt wurde. Dazu wird auch alles neu erstellt, was von python abhängt, einschließlich python-notebook.

Intern funktioniert --without-tests, indem es die Option #:tests? der check-Phase eines Pakets abändert (siehe Erstellungssysteme). Beachten Sie, dass manche Pakete eine angepasste check-Phase benutzen, die eine Einstellung wie #:tests? #f nicht berücksichtigt. Deshalb wirkt sich --without-tests auf diese Pakete nicht aus.

Sie fragen sich sicher, wie Sie dieselbe Wirkung mit Scheme-Code erzielen können, zum Beispiel wenn Sie Ihr Manifest oder eine eigene Paketumwandlung schreiben? Siehe Paketvarianten definieren für eine Übersicht über verfügbare Programmierschnittstellen.


Nächste: , Vorige: , Nach oben: Aufruf von guix build   [Inhalt][Index]