Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]


6.3 Erstellungssysteme

Jede Paketdefinition legt ein Erstellungssystem („build system“) sowie dessen Argumente fest (siehe Pakete definieren). Das build-system-Feld steht für die Erstellungsprozedur des Pakets sowie für weitere implizite Eingaben für die Erstellungsprozedur.

Erstellungssysteme sind <build-system>-Objekte. Die Schnittstelle, um solche zu erzeugen und zu verändern, ist im Modul (guix build-system) zu finden, und die eigentlichen Erstellungssysteme werden jeweils von ihren eigenen Modulen exportiert.

Intern funktionieren Erstellungssysteme, indem erst Paketobjekte zu Bags kompiliert werden. Eine Bag (deutsch: Beutel, Sack) ist wie ein Paket, aber mit weniger Zierrat — anders gesagt ist eine Bag eine systemnähere Darstellung eines Pakets, die sämtliche Eingaben des Pakets einschließlich vom Erstellungssystem hinzugefügter Eingaben enthält. Diese Zwischendarstellung wird dann zur eigentlichen Ableitung kompiliert (siehe Ableitungen).

Erstellungssysteme akzeptieren optional eine Liste von Argumenten. In Paketdefinitionen werden diese über das arguments-Feld übergeben (siehe Pakete definieren). Sie sind in der Regel Schlüsselwort-Argumente (siehe keyword arguments in Guile in GNU Guile Reference Manual). Der Wert dieser Argumente wird normalerweise vom Erstellungssystem in der Erstellungsschicht ausgewertet, d.h. von einem durch den Daemon gestarteten Guile-Prozess (siehe Ableitungen).

Das häufigste Erstellungssystem ist gnu-build-system, was die übliche Erstellungsprozedur für GNU-Pakete und viele andere Pakete darstellt. Es wird vom Modul (guix build-system gnu) bereitgestellt.

Scheme-Variable: gnu-build-system

gnu-build-system steht für das GNU-Erstellungssystem und Varianten desselben (siehe configuration and makefile conventions in GNU Coding Standards).

Kurz gefasst werden Pakete, die es benutzen, konfiguriert, erstellt und installiert mit der üblichen Befehlsfolge ./configure && make && make check && make install. In der Praxis braucht man oft noch ein paar weitere Schritte. Alle Schritte sind in voneinander getrennte Phasen unterteilt. Erwähnt werden sollten15:

unpack

Den Quell-Tarball entpacken und das Arbeitsverzeichnis wechseln in den entpackten Quellbaum. Wenn die Quelle bereits ein Verzeichnis ist, wird es in den Quellbaum kopiert und dorthin gewechselt.

patch-source-shebangs

„Shebangs“ in Quelldateien beheben, damit Sie sich auf die richtigen Store-Dateipfade beziehen. Zum Beispiel könnte #!/bin/sh zu #!/gnu/store/…-bash-4.3/bin/sh geändert werden.

configure

Das Skript configure mit einigen vorgegebenen Befehlszeilenoptionen ausführen, wie z.B. mit --prefix=/gnu/store/…, sowie mit den im #:configure-flags-Argument angegebenen Optionen.

build

make ausführen mit den Optionen aus der Liste in #:make-flags. Wenn das Argument #:parallel-build? auf wahr gesetzt ist (was der Vorgabewert ist), wird make -j zum Erstellen ausgeführt.

check

make check (oder statt check ein anderes bei #:test-target angegebenes Ziel) ausführen, außer falls #:tests? #f gesetzt ist. Wenn das Argument #:parallel-tests? auf wahr gesetzt ist (der Vorgabewert), führe make check -j aus.

install

make install mit den in #:make-flags aufgelisteten Optionen ausführen.

patch-shebangs

Shebangs in den installierten ausführbaren Dateien beheben.

strip

Symbole zur Fehlerbehebung aus ELF-Dateien entfernen (außer #:strip-binaries? ist auf falsch gesetzt) und in die debug-Ausgabe kopieren, falls diese verfügbar ist (siehe Dateien zur Fehlersuche installieren).

Das erstellungsseitige Modul (guix build gnu-build-system) definiert %standard-phases als die vorgegebene Liste der Erstellungsphasen. %standard-phases ist eine Liste von Paaren aus je einem Symbol und einer Prozedur. Letztere implementiert die eigentliche Phase.

Die Liste der Phasen, die für ein bestimmtes Paket verwendet werden sollen, kann vom Parameter #:phases überschrieben werden. Zum Beispiel werden bei Übergabe von:

#:phases (modify-phases %standard-phases (delete 'configure))

alle oben beschriebenen Phasen benutzt außer der configure-Phase.

Zusätzlich stellt dieses Erstellungssystem sicher, dass die „Standard“-Umgebung für GNU-Pakete zur Verfügung steht. Diese umfasst Werkzeuge wie GCC, libc, Coreutils, Bash, Make, Diffutils, grep und sed (siehe das Modul (guix build-system gnu) für eine vollständige Liste). Wir bezeichnen sie als implizite Eingaben eines Pakets, weil Paketdefinitionen sie nicht aufführen müssen.

Andere <build-system>-Objekte werden definiert, um andere Konventionen und Werkzeuge von Paketen für freie Software zu unterstützen. Die anderen Erstellungssysteme erben den Großteil vom gnu-build-system und unterscheiden sich hauptsächlich darin, welche Eingaben dem Erstellungsprozess implizit hinzugefügt werden und welche Liste von Phasen durchlaufen wird. Manche dieser Erstellungssysteme sind im Folgenden aufgeführt.

Scheme-Variable: ant-build-system

Diese Variable wird vom Modul (guix build-system ant) exportiert. Sie implementiert die Erstellungsprozedur für Java-Pakete, die mit dem Ant build tool erstellt werden können.

Sowohl ant als auch der Java Development Kit (JDK), wie er vom Paket icedtea bereitgestellt wird, werden zu den Eingaben hinzugefügt. Wenn andere Pakete dafür benutzt werden sollen, können sie jeweils mit den Parametern #:ant und #:jdk festgelegt werden.

Falls das ursprüngliche Paket über keine nutzbare Ant-Erstellungsdatei („Ant-Buildfile“) verfügt, kann aus der Angabe im Parameter #:jar-name eine minimale Ant-Erstellungsdatei build.xml erzeugt werden, in der die für die Erstellung durchzuführenden Aufgaben (Tasks) für die Erstellung des angegebenen Jar-Archivs stehen. In diesem Fall kann der Parameter #:source-dir benutzt werden, um das Unterverzeichnis mit dem Quellcode anzugeben; sein Vorgabewert ist „src“.

Der Parameter #:main-class kann mit einer minimalen Ant-Erstellungsdatei benutzt werden, um die Hauptklasse des resultierenden Jar-Archivs anzugeben. Dies ist nötig, wenn die Jar-Datei ausführbar sein soll. Mit dem Parameter #:test-include kann eine Liste angegeben werden, welche Junit-Tests auszuführen sind. Der Vorgabewert ist (list "**/*Test.java"). Mit #:test-exclude kann ein Teil der Testdateien ignoriert werden. Der Vorgabewert ist (list "**/Abstract*.java"), weil abstrakte Klassen keine ausführbaren Tests enthalten können.

Der Parameter #:build-target kann benutzt werden, um die Ant-Aufgabe (Task) anzugeben, die während der build-Phase ausgeführt werden soll. Vorgabe ist, dass die Aufgabe (Task) „jar“ ausgeführt wird.

Scheme-Variable: android-ndk-build-system

Diese Variable wird von (guix build-system android-ndk) exportiert. Sie implementiert eine Erstellungsprozedur für das Android NDK (Native Development Kit) benutzende Pakete mit einem Guix-spezifischen Erstellungsprozess.

Für das Erstellungssystem wird angenommen, dass Pakete die zu ihrer öffentlichen Schnittstelle gehörenden Header-Dateien im Unterverzeichnis "include" der Ausgabe "out" und ihre Bibliotheken im Unterverzeichnis "lib" der Ausgabe "out" platzieren.

Ebenso wird angenommen, dass es keine im Konflikt stehenden Dateien unter der Vereinigung aller Abhängigkeiten gibt.

Derzeit wird Cross-Kompilieren hierfür nicht unterstützt, also wird dabei vorausgesetzt, dass Bibliotheken und Header-Dateien dieselben wie im Wirtssystem sind.

Scheme-Variable: asdf-build-system/source
Scheme-Variable: asdf-build-system/sbcl
Scheme-Variable: asdf-build-system/ecl

Diese Variablen, die vom Modul (guix build-system asdf) exportiert werden, implementieren Erstellungsprozeduren für Common-Lisp-Pakete, welche „ASDF“ benutzen. ASDF dient der Systemdefinition für Common-Lisp-Programme und -Bibliotheken.

Das Erstellungssystem asdf-build-system/source installiert die Pakete in Quellcode-Form und kann via ASDF mit jeder Common-Lisp-Implementierung geladen werden. Die anderen Erstellungssysteme wie asdf-build-system/sbcl installieren binäre Systeme in dem Format, das von einer bestimmten Implementierung verstanden wird. Diese Erstellungssysteme können auch benutzt werden, um ausführbare Programme zu erzeugen oder um Lisp-Abbilder mit einem vorab geladenen Satz von Paketen zu erzeugen.

Das Erstellungssystem benutzt gewisse Namenskonventionen. Bei Binärpaketen sollte dem Paketnamen die Lispimplementierung als Präfix vorangehen, z.B. sbcl- für asdf-build-system/sbcl.

Zudem sollte das entsprechende Quellcode-Paket mit der Konvention wie bei Python-Paketen (siehe Python-Module) ein cl- als Präfix bekommen.

Für Binärpakete sollte für jedes System ein Guix-Paket definiert werden. Wenn für einen Ursprung im origin mehrere Systeme enthalten sind, können Paketvarianten geschrieben werden, mit denen alle Systeme erstellt werden. Quellpakete, die asdf-build-system/source benutzen, können mehrere Systeme enthalten.

Um ausführbare Programme und Abbilder zu erzeugen, können die erstellungsseitigen Prozeduren build-program und build-image benutzt werden. Sie sollten in einer Erstellungsphase nach der create-symlinks-Phase aufgerufen werden, damit das gerade erstellte System Teil des resultierenden Abbilds sein kann. An build-program muss eine Liste von Common-Lisp-Ausdrücken über das Argument #:entry-program übergeben werden.

Wenn das System nicht in seiner eigenen gleichnamigen .asd-Datei definiert ist, sollte der Parameter #:asd-file benutzt werden, um anzugeben, in welcher Datei das System definiert ist. Außerdem wird bei Paketen, für deren Tests ein System in einer separaten Datei definiert wurde, dieses System geladen, bevor die Tests ablaufen, wenn es im Parameter #:test-asd-file steht. Ist dafür kein Wert gesetzt, werden die Dateien <system>-tests.asd, <system>-test.asd, tests.asd und test.asd durchsucht, wenn sie existieren.

Wenn aus irgendeinem Grund der Paketname nicht den Namenskonventionen folgen kann, kann der Parameter #:asd-system-name benutzt werden, um den Namen des Systems anzugeben.

Scheme-Variable: cargo-build-system

Diese Variable wird vom Modul (guix build-system cargo) exportiert. Damit können Pakete mit Cargo erstellt werden, dem Erstellungswerkzeug der Rust-Programmiersprache.

Das Erstellungssystem fügt rustc und cargo zu den Eingaben hinzu. Ein anderes Rust-Paket kann mit dem Parameter #:rust angegeben werden.

Normale cargo-Abhängigkeiten sollten zur Paketdefinition über den Parameter #:cargo-inputs als eine Liste von Paaren aus Name und Spezifikation hinzugefügt werden, wobei als Spezifikation ein Paket oder eine Quellcode-Definition angegeben werden kann. Beachten Sie, dass die Spezifikation zu einem mit gzip komprimierten Tarball ausgewertet werden muss, der eine Datei Cargo.toml in seinem Wurzelverzeichnis enthält, ansonsten wird sie ignoriert. Analog sollten solche Abhängigkeiten, die in cargo als „dev-dependencies“ deklariert werden, zur Paketdefinition über den Parameter #:cargo-development-inputs hinzugefügt werden.

In seiner configure-Phase sorgt dieses Erstellungssystem dafür, dass cargo alle Quellcodeeingaben zur Verfügung stehen, die in den Parametern #:cargo-inputs und #:cargo-development-inputs angegeben wurden. Außerdem wird eine enthaltene Cargo.lock-Datei entfernt, damit cargo selbige während der build-Phase neu erzeugt. Die install-Phase installiert die in jeder Crate definierten Binärdateien.

Scheme-Variable: copy-build-system

Diese Variable wird vom Modul (guix build-system copy) exportiert. Damit können einfache Pakete erstellt werden, für die nur wenig kompiliert werden muss, sondern in erster Linie Dateien kopiert werden.

Dadurch wird ein Großteil der gnu-build-system zur Menge der Paketeingaben hinzugefügt. Deswegen kann man bei Nutzung des copy-build-system auf große Teile des Codes verzichten, der beim trivial-build-system anfallen würde.

Um den Dateiinstallationsvorgang weiter zu vereinfachen, wird ein Argument #:install-plan zur Verfügung gestellt, mit dem der Paketautor angeben kann, welche Dateien wohin gehören. Der Installationsplan ist eine Liste aus (Quelle Ziel [Filter]). Die Filter sind optional.

Beispiele:

Scheme-Variable: clojure-build-system

Diese Variable wird durch das Modul (guix build-system clojure) exportiert. Sie implementiert eine einfache Erstellungsprozedur für in Clojure geschriebene Pakete mit dem guten alten compile in Clojure. Cross-Kompilieren wird noch nicht unterstützt.

Das Erstellungssystem fügt clojure, icedtea und zip zu den Eingaben hinzu. Sollen stattdessen andere Pakete benutzt werden, können diese jeweils mit den Parametern #:clojure, #:jdk und #:zip spezifiziert werden.

Eine Liste der Quellcode-Verzeichnisse, Test-Verzeichnisse und Namen der Jar-Dateien können jeweils über die Parameter #:source-dirs, #:test-dirs und #:jar-names angegeben werden. Das Verzeichnis, in das kompiliert wird, sowie die Hauptklasse können jeweils mit den Parametern #:compile-dir und #:main-class angegeben werden. Andere Parameter sind im Folgenden dokumentiert.

Dieses Erstellungssystem ist eine Erweiterung des ant-build-system, bei der aber die folgenden Phasen geändert wurden:

build

Diese Phase ruft compile in Clojure auf, um Quelldateien zu kompilieren, und führt jar aus, um Jar-Dateien aus sowohl Quelldateien als auch kompilierten Dateien zu erzeugen, entsprechend der jeweils in #:aot-include und #:aot-exclude festgelegten Listen aus in der Menge der Quelldateien eingeschlossenen und ausgeschlossenen Bibliotheken. Die Ausschlussliste hat Vorrang vor der Einschlussliste. Diese Listen setzen sich aus Symbolen zusammen, die für Clojure-Bibliotheken stehen oder dem Schlüsselwort #:all entsprechen, was für alle im Quellverzeichis gefundenen Clojure-Bibliotheken steht. Der Parameter #:omit-source? entscheidet, ob Quelldateien in die Jar-Archive aufgenommen werden sollen.

check

In dieser Phase werden Tests auf die durch Einschluss- und Ausschlussliste #:test-include bzw. #:test-exclude angegebenen Dateien ausgeführt. Deren Bedeutung ist analog zu #:aot-include und #:aot-exclude, außer dass das besondere Schlüsselwort #:all jetzt für alle Clojure-Bibliotheken in den Test-Verzeichnissen steht. Der Parameter #:tests? entscheidet, ob Tests ausgeführt werden sollen.

install

In dieser Phase werden alle zuvor erstellten Jar-Dateien installiert.

Zusätzlich zu den bereits angegebenen enthält dieses Erstellungssystem noch eine weitere Phase.

install-doc

Diese Phase installiert alle Dateien auf oberster Ebene, deren Basisnamen ohne Verzeichnisangabe zu %doc-regex passen. Ein anderer regulärer Ausdruck kann mit dem Parameter #:doc-regex verwendet werden. All die so gefundenen oder (rekursiv) in den mit #:doc-dirs angegebenen Dokumentationsverzeichnissen liegenden Dateien werden installiert.

Scheme-Variable: cmake-build-system

Diese Variable wird von (guix build-system cmake) exportiert. Sie implementiert die Erstellungsprozedur für Pakete, die das CMake-Erstellungswerkzeug benutzen.

Das Erstellungssystem fügt automatisch das Paket cmake zu den Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter #:cmake geändert werden.

Der Parameter #:configure-flags wird als Liste von Befehlszeilenoptionen aufgefasst, die an den Befehl cmake übergeben werden. Der Parameter #:build-type abstrahiert, welche Befehlszeilenoptionen dem Compiler übergeben werden; der Vorgabewert ist "RelWithDebInfo" (kurz für „release mode with debugging information“), d.h. kompiliert wird für eine Produktionsumgebung und Informationen zur Fehlerbehebung liegen bei, was ungefähr -O2 -g entspricht, wie bei der Vorgabe für Autoconf-basierte Pakete.

Scheme-Variable: dune-build-system

Diese Variable wird vom Modul (guix build-system dune) exportiert. Sie unterstützt es, Pakete mit Dune zu erstellen, einem Erstellungswerkzeug für die Programmiersprache OCaml, und ist als Erweiterung des unten beschriebenen OCaml-Erstellungssystems ocaml-build-system implementiert. Als solche können auch die Parameter #:ocaml und #:findlib an dieses Erstellungssystem übergeben werden.

Das Erstellungssystem fügt automatisch das Paket dune zu den Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter #:dune geändert werden.

Es gibt keine configure-Phase, weil dune-Pakete typischerweise nicht konfiguriert werden müssen. Vom Parameter #:build-flags wird erwartet, dass es sich um eine Liste von Befehlszeilenoptionen handelt, die zur Erstellung an den dune-Befehl übergeben werden.

Der Parameter #:jbuild? kann übergeben werden, um den Befehl jbuild anstelle des neueren dune-Befehls aufzurufen, um das Paket zu erstellen. Der Vorgabewert ist #f.

Mit dem Parameter #:package kann ein Paketname angegeben werden, wenn im Paket mehrere Pakete enthalten sind und nur eines davon erstellt werden soll. Es ist äquivalent dazu, die Befehlszeilenoption -p an dune zu übergeben.

Scheme-Variable: go-build-system

Diese Variable wird vom Modul (guix build-system go) exportiert. Mit ihr ist eine Erstellungsprozedur für Go-Pakete implementiert, die dem normalen Go-Erstellungsmechanismus entspricht.

Beim Aufruf wird ein Wert für den Schlüssel #:import-path und manchmal auch für #:unpack-path erwartet. Der „import path“ entspricht dem Dateisystempfad, den die Erstellungsskripts des Pakets und darauf Bezug nehmende Pakete erwarten; durch ihn wird ein Go-Paket eindeutig bezeichnet. Typischerweise setzt er sich aus einer Kombination der entfernten URI des Paketquellcodes und der Dateisystemhierarchie zusammen. Manchmal ist es nötig, den Paketquellcode in ein anderes als das vom „import path“ bezeichnete Verzeichnis zu entpacken; diese andere Verzeichnisstruktur sollte dann als #:unpack-path angegeben werden.

Pakete, die Go-Bibliotheken zur Verfügung stellen, sollten ihren Quellcode auch in die Erstellungsausgabe installieren. Der Schlüssel #:install-source?, sein Vorgabewert ist #t, steuert, ob Quellcode installiert wird. Bei Paketen, die nur ausführbare Dateien liefern, kann der Wert auf #f gesetzt werden.

Scheme-Variable: glib-or-gtk-build-system

Diese Variable wird vom Modul (guix build-system glib-or-gtk) exportiert. Sie ist für Pakete gedacht, die GLib oder GTK benutzen.

Dieses Erstellungssystem fügt die folgenden zwei Phasen zu denen von gnu-build-system hinzu:

glib-or-gtk-wrap

Die Phase glib-or-gtk-wrap stellt sicher, dass Programme in bin/ in der Lage sind, GLib-„Schemata“ und GTK-Module zu finden. Dazu wird für das Programm ein Wrapper-Skript erzeugt, dass das eigentliche Programm mit den richtigen Werten für die Umgebungsvariablen XDG_DATA_DIRS und GTK_PATH aufruft.

Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess auszunehmen, indem Sie eine Liste ihrer Namen im Parameter #:glib-or-gtk-wrap-excluded-outputs angeben. Das ist nützlich, wenn man von einer Ausgabe weiß, dass sie keine Binärdateien enthält, die GLib oder GTK benutzen, und diese Ausgabe durch das Wrappen ohne Not eine weitere Abhängigkeit von GLib und GTK bekäme.

glib-or-gtk-compile-schemas

Mit der Phase glib-or-gtk-compile-schemas wird sichergestellt, dass alle GSettings-Schemata für GLib kompiliert werden. Dazu wird das Programm glib-compile-schemas ausgeführt. Es kommt aus dem Paket glib:bin, was automatisch vom Erstellungssystem importiert wird. Welches glib-Paket dieses glib-compile-schemas bereitstellt, kann mit dem Parameter #:glib spezifiziert werden.

Beide Phasen finden nach der install-Phase statt.

Scheme-Variable: guile-build-system

Dieses Erstellungssystem ist für Guile-Pakete gedacht, die nur aus Scheme-Code bestehen und so schlicht sind, dass sie nicht einmal ein Makefile und erst recht keinen configure-Skript enthalten. Hierzu wird Scheme-Code mit guild compile kompiliert (siehe Compilation in GNU Guile Reference Manual) und die .scm- und .go-Dateien an den richtigen Pfad installiert. Auch Dokumentation wird installiert.

Das Erstellungssystem unterstützt Cross-Kompilieren durch die Befehlszeilenoption --target für guild compile.

Mit guile-build-system erstellte Pakete müssen ein Guile-Paket in ihrem native-inputs-Feld aufführen.

Scheme-Variable: julia-build-system

Diese Variable wird vom Modul (guix build-system julia) exportiert. Sie entspricht einer Implementierung der durch Julia-Pakete genutzten Erstellungsprozedur und verhält sich in Prinzip so, wie wenn man julia -e 'using Pkg; Pkg.add(paket)' in einer Umgebung auszuführt, in der die Umgebungsvariable JULIA_LOAD_PATH die Pfade aller Julia-Pakete unter den Paketeingaben enthält. Es werden keine Tests ausgeführt.

Für Julia-Pakete wird vorausgesetzt, dass der Dateiname im file-name-Feld der Quelle der echte Name des Pakets ist, in der richtigen Groß-/Kleinschreibung.

Für Pakete, die als Abhängigkeiten gemeinsame Bibliotheken („Shared Libraries“) verlangen, müssen Sie die /deps/deps.jl-Datei unter Umständen selbst schreiben. Normalerweise enthält sie eine Zeile wie const variable = /gnu/store/library.so für jede Abhängigkeit sowie eine Funktion check_deps() = nothing ohne Rückgabe.

Für manche ältere Pakete, die noch keine Package.toml benutzen, muss auch diese Datei erstellt werden. Die Funktion julia-create-package-toml hilft dabei. Sie müssen ihr nur die Ausgaben und die Quelle des Pakets übergeben sowie seinen Namen (derselbe wie beim Parameter file-name), die Paket-UUID, die Paketversion und eine Liste von Abhängigkeiten, jeweils angegeben über ihren Namen und ihre UUID.

Scheme-Variable: minify-build-system

Diese Variable wird vom Modul (guix build-system minify) exportiert. Sie implementiert eine Prozedur zur Minifikation einfacher JavaScript-Pakete.

Es fügt uglify-js zur Menge der Eingaben hinzu und komprimiert damit alle JavaScript-Dateien im src-Verzeichnis. Ein anderes Programm zur Minifikation kann verwendet werden, indem es mit dem Parameter #:uglify-js angegeben wird; es wird erwartet, dass das angegebene Paket den minifizierten Code auf der Standardausgabe ausgibt.

Wenn die Eingabe-JavaScript-Dateien nicht alle im src-Verzeichnis liegen, kann mit dem Parameter #:javascript-files eine Liste der Dateinamen übergeben werden, auf die das Minifikationsprogramm aufgerufen wird.

Scheme-Variable: ocaml-build-system

Diese Variable wird vom Modul (guix build-system ocaml) exportiert. Mit ihr ist ein Erstellungssystem für OCaml-Pakete implementiert, was bedeutet, dass es die richtigen auszuführenden Befehle für das jeweilige Paket auswählt. OCaml-Pakete können sehr unterschiedliche Befehle erwarten. Dieses Erstellungssystem probiert manche davon durch.

Wenn im Paket eine Datei setup.ml auf oberster Ebene vorhanden ist, wird ocaml setup.ml -configure, ocaml setup.ml -build und ocaml setup.ml -install ausgeführt. Das Erstellungssystem wird annehmen, dass die Datei durch OASIS erzeugt wurde, und wird das Präfix setzen und Tests aktivieren, wenn diese nicht abgeschaltet wurden. Sie können Befehlszeilenoptionen zum Konfigurieren und Erstellen mit den Parametern #:configure-flags und #:build-flags übergeben. Der Schlüssel #:test-flags kann übergeben werden, um die Befehlszeilenoptionen zu ändern, mit denen die Tests aktiviert werden. Mit dem Parameter #:use-make? kann dieses Erstellungssystem für die build- und install-Phasen abgeschaltet werden.

Verfügt das Paket über eine configure-Datei, wird angenommen, dass diese von Hand geschrieben wurde mit einem anderen Format für Argumente als bei einem Skript des gnu-build-system. Sie können weitere Befehlszeilenoptionen mit dem Schlüssel #:configure-flags hinzufügen.

Falls dem Paket ein Makefile beiliegt (oder #:use-make? auf #t gesetzt wurde), wird dieses benutzt und weitere Befehlszeilenoptionen können mit dem Schlüssel #:make-flags zu den build- und install-Phasen hinzugefügt werden.

Letztlich gibt es in manchen Pakete keine solchen Dateien, sie halten sich aber an bestimmte Konventionen, wo ihr eigenes Erstellungssystem zu finden ist. In diesem Fall führt Guix’ OCaml-Erstellungssystem ocaml pkg/pkg.ml oder ocaml pkg/build.ml aus und kümmert sich darum, dass der Pfad zu dem benötigten findlib-Modul passt. Weitere Befehlszeilenoptionen können über den Schlüssel #:build-flags übergeben werden. Um die Installation kümmert sich opam-installer. In diesem Fall muss das opam-Paket im native-inputs-Feld der Paketdefinition stehen.

Beachten Sie, dass die meisten OCaml-Pakete davon ausgehen, dass sie in dasselbe Verzeichnis wie OCaml selbst installiert werden, was wir in Guix aber nicht so haben wollen. Solche Pakete installieren ihre .so-Dateien in das Verzeichnis ihres Moduls, was für die meisten anderen Einrichtungen funktioniert, weil es im OCaml-Compilerverzeichnis liegt. Jedoch können so in Guix die Bibliotheken nicht gefunden werden, deswegen benutzen wir CAML_LD_LIBRARY_PATH. Diese Umgebungsvariable zeigt auf lib/ocaml/site-lib/stubslibs und dorthin sollten .so-Bibliotheken installiert werden.

Scheme-Variable: python-build-system

Diese Variable wird vom Modul (guix build-system python) exportiert. Sie implementiert mehr oder weniger die konventionelle Erstellungsprozedur, wie sie für Python-Pakete üblich ist, d.h. erst wird python setup.py build ausgeführt und dann python setup.py install --prefix=/gnu/store/….

Für Pakete, die eigenständige Python-Programme nach bin/ installieren, sorgt dieses Erstellungssystem dafür, dass die Programme in ein Wrapper-Skript verpackt werden, welches die eigentlichen Programme mit einer Umgebungsvariablen PYTHONPATH aufruft, die alle Python-Bibliotheken auflistet, von denen die Programme abhängen.

Welches Python-Paket benutzt wird, um die Erstellung durchzuführen, kann mit dem Parameter #:python bestimmt werden. Das ist nützlich, wenn wir erzwingen wollen, dass ein Paket mit einer bestimmten Version des Python-Interpretierers arbeitet. Das kann nötig sein, wenn das Programm nur mit einer einzigen Interpretiererversion kompatibel ist.

Standardmäßig ruft Guix setup.py auf, was zu setuptools gehört, ähnlich wie es auch pip tut. Manche Pakete sind mit setuptools (und pip) inkompatibel, deswegen können Sie diese Einstellung abschalten, indem Sie den Parameter #:use-setuptools? auf #f setzen.

Scheme-Variable: perl-build-system

Diese Variable wird vom Modul (guix build-system perl) exportiert. Mit ihr wird die Standard-Erstellungsprozedur für Perl-Pakete implementiert, welche entweder darin besteht, perl Build.PL --prefix=/gnu/store/… gefolgt von Build und Build install auszuführen, oder perl Makefile.PL PREFIX=/gnu/store/… gefolgt von make und make install auszuführen, je nachdem, ob eine Datei Build.PL oder eine Datei Makefile.PL in der Paketdistribution vorliegt. Den Vorrang hat erstere, wenn sowohl Build.PL als auch Makefile.PL in der Paketdistribution existieren. Der Vorrang kann umgekehrt werden, indem #t für den Parameter #:make-maker? angegeben wird.

Der erste Aufruf von perl Makefile.PL oder perl Build.PL übergibt die im Parameter #:make-maker-flags bzw. #:module-build-flags angegebenen Befehlszeilenoptionen, je nachdem, was verwendet wird.

Welches Perl-Paket dafür benutzt wird, kann mit #:perl angegeben werden.

Scheme-Variable: qt-build-system

Diese Variable wird vom Modul (guix build-system qt) exportiert. Sie ist für Anwendungen gedacht, die Qt oder KDE benutzen.

Dieses Erstellungssystem fügt die folgenden zwei Phasen zu denen von cmake-build-system hinzu:

check-setup

Die Phase check-setup bereitet die Umgebung für Überprüfungen vor, wie sie von Qt-Test-Programmen üblicherweise benutzt werden. Zur Zeit werden nur manche Umgebungsvariable gesetzt: QT_QPA_PLATFORM=offscreen, DBUS_FATAL_WARNINGS=0 und CTEST_OUTPUT_ON_FAILURE=1.

Diese Phase wird vor der check-Phase hinzugefügt. Es handelt sich um eine eigene Phase, die nach Bedarf angepasst werden kann.

qt-wrap

In der Phase qt-wrap wird nach Qt5-Plugin-Pfaden, QML-Pfaden und manchen XDG-Daten in den Ein- und Ausgaben gesucht. Wenn solch ein Pfad gefunden wird, werden für alle Programme in den Verzeichnissen bin/, sbin/, libexec/ und lib/libexec/ in der Ausgabe Wrapper-Skripte erzeugt, die die nötigen Umgebungsvariablen definieren.

Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess auszunehmen, indem Sie eine Liste ihrer Namen im Parameter #:qt-wrap-excluded-outputs angeben. Das ist nützlich, wenn man von einer Ausgabe weiß, dass sie keine Qt-Binärdateien enthält, und diese Ausgabe durch das Wrappen ohne Not eine weitere Abhängigkeit von Qt, KDE oder Ähnlichem bekäme.

Diese Phase wird nach der install-Phase hinzugefügt.

Scheme-Variable: r-build-system

Diese Variable wird vom Modul (guix build-system r) exportiert. Sie entspricht einer Implementierung der durch R-Pakete genutzten Erstellungsprozedur, die wenig mehr tut, als R CMD INSTALL --library=/gnu/store/… in einer Umgebung auszuführen, in der die Umgebungsvariable R_LIBS_SITE die Pfade aller R-Pakete unter den Paketeingaben enthält. Tests werden nach der Installation mit der R-Funktion tools::testInstalledPackage ausgeführt.

Scheme-Variable: rakudo-build-system

Diese Variable wird vom Modul (guix build-system rakudo) exportiert. Sie implementiert die Erstellungsprozedur, die von Rakudo für Perl6-Pakete benutzt wird. Pakete werden ins Verzeichnis /gnu/store/…/NAME-VERSION/share/perl6 abgelegt und Binärdateien, Bibliotheksdateien und Ressourcen werden installiert, zudem werden die Dateien im Verzeichnis bin/ in Wrapper-Skripte verpackt. Tests können übersprungen werden, indem man #f im Parameter tests? übergibt.

Welches rakudo-Paket benutzt werden soll, kann mit dem Parameter rakudo angegeben werden. Das perl6-tap-harness-Paket, das für die Tests benutzt wird, kann mit #:prove6 ausgewählt werden; es kann auch entfernt werden, indem man #f für den Parameter with-prove6? übergibt. Welches perl6-zef-Paket für Tests und Installation verwendet wird, kann mit dem Parameter #:zef angegeben werden; es kann auch entfernt werden, indem man #f für den Parameter with-zef? übergibt.

Scheme-Variable: texlive-build-system

Diese Variable wird vom Modul (guix build-system texlive) exportiert. Mit ihr werden TeX-Pakete in Stapelverarbeitung („batch mode“) mit der angegebenen Engine erstellt. Das Erstellungssystem setzt die Variable TEXINPUTS so, dass alle TeX-Quelldateien unter den Eingaben gefunden werden können.

Standardmäßig wird luatex auf allen Dateien mit der Dateiendung ins ausgeführt. Eine andere Engine oder ein anderes Format kann mit dem Argument #:tex-format angegeben werden. Verschiedene Erstellungsziele können mit dem Argument #:build-targets festgelegt werden, das eine Liste von Dateinamen erwartet. Das Erstellungssystem fügt nur texlive-bin und texlive-latex-base zu den Eingaben hinzu (beide kommen aus dem Modul (gnu packages tex). Für beide kann das zu benutzende Paket jeweils mit den Argumenten #:texlive-bin oder #:texlive-latex-base geändert werden.

Der Parameter #:tex-directory sagt dem Erstellungssystem, wohin die installierten Dateien im texmf-Verzeichnisbaum installiert werden sollen.

Scheme-Variable: ruby-build-system

Diese Variable wird vom Modul (guix build-system ruby) exportiert. Sie steht für eine Implementierung der RubyGems-Erstellungsprozedur, die für Ruby-Pakete benutzt wird, wobei gem build gefolgt von gem install ausgeführt wird.

Das source-Feld eines Pakets, das dieses Erstellungssystem benutzt, verweist typischerweise auf ein Gem-Archiv, weil Ruby-Entwickler dieses Format benutzen, wenn sie ihre Software veröffentlichen. Das Erstellungssystem entpackt das Gem-Archiv, spielt eventuell Patches für den Quellcode ein, führt die Tests aus, verpackt alles wieder in ein Gem-Archiv und installiert dieses. Neben Gem-Archiven darf das Feld auch auf Verzeichnisse und Tarballs verweisen, damit es auch möglich ist, unveröffentlichte Gems aus einem Git-Repository oder traditionelle Quellcode-Veröffentlichungen zu benutzen.

Welches Ruby-Paket benutzt werden soll, kann mit dem Parameter #:ruby festgelegt werden. Eine Liste zusätzlicher Befehlszeilenoptionen für den Aufruf des gem-Befehls kann mit dem Parameter #:gem-flags angegeben werden.

Scheme-Variable: waf-build-system

Diese Variable wird durch das Modul (guix build-system waf) exportiert. Damit ist eine Erstellungsprozedur rund um das waf-Skript implementiert. Die üblichen Phasen — configure, build und install — sind implementiert, indem deren Namen als Argumente an das waf-Skript übergeben werden.

Das waf-Skript wird vom Python-Interpetierer ausgeführt. Mit welchem Python-Paket das Skript ausgeführt werden soll, kann mit dem Parameter #:python angegeben werden.

Scheme-Variable: scons-build-system

Diese Variable wird vom Modul (guix build-system scons) exportiert. Sie steht für eine Implementierung der Erstellungsprozedur, die das SCons-Softwarekonstruktionswerkzeug („software construction tool“) benutzt. Das Erstellungssystem führt scons aus, um das Paket zu erstellen, führt mit scons test Tests aus und benutzt scons install, um das Paket zu installieren.

Zusätzliche Optionen, die an scons übergeben werden sollen, können mit dem Parameter #:scons-flags angegeben werden. Die voreingestellten Erstellungs- und Installationsziele können jeweils durch #:build-targets und #:install-targets ersetzt werden. Die Python-Version, die benutzt werden soll, um SCons auszuführen, kann festgelegt werden, indem das passende SCons-Paket mit dem Parameter #:scons ausgewählt wird.

Scheme-Variable: haskell-build-system

Diese Variable wird vom Modul (guix build-system haskell) exportiert. Sie bietet Zugang zur Cabal-Erstellungsprozedur, die von Haskell-Paketen benutzt wird, was bedeutet, runhaskell Setup.hs configure --prefix=/gnu/store/… und runhaskell Setup.hs build auszuführen. Statt das Paket mit dem Befehl runhaskell Setup.hs install zu installieren, benutzt das Erstellungssystem runhaskell Setup.hs copy gefolgt von runhaskell Setup.hs register, um keine Bibliotheken im Store-Verzeichnis des Compilers zu speichern, auf dem keine Schreibberechtigung besteht. Zusätzlich generiert das Erstellungssystem Dokumentation durch Ausführen von runhaskell Setup.hs haddock, außer #:haddock? #f wurde übergeben. Optional können an Haddock Parameter mit Hilfe des Parameters #:haddock-flags übergeben werden. Wird die Datei Setup.hs nicht gefunden, sucht das Erstellungssystem stattdessen nach Setup.lhs.

Welcher Haskell-Compiler benutzt werden soll, kann über den #:haskell-Parameter angegeben werden. Als Vorgabewert verwendet er ghc.

Scheme-Variable: dub-build-system

Diese Variable wird vom Modul (guix build-system dub) exportiert. Sie verweist auf eine Implementierung des Dub-Erstellungssystems, das von D-Paketen benutzt wird. Dabei werden dub build und dub run ausgeführt. Die Installation wird durch manuelles Kopieren der Dateien durchgeführt.

Welcher D-Compiler benutzt wird, kann mit dem Parameter #:ldc festgelegt werden, was als Vorgabewert ldc benutzt.

Scheme-Variable: emacs-build-system

Diese Variable wird vom Modul (guix build-system emacs) exportiert. Darin wird eine Installationsprozedur ähnlich der des Paketsystems von Emacs selbst implementiert (siehe Packages in The GNU Emacs Manual).

Zunächst wird eine Datei Paket-autoloads.el erzeugt, dann werden alle Emacs-Lisp-Dateien zu Bytecode kompiliert. Anders als beim Emacs-Paketsystem werden die Info-Dokumentationsdateien in das Standardverzeichnis für Dokumentation verschoben und die Datei dir gelöscht. Die Dateien des Elisp-Pakets werden direkt in share/emacs/site-lisp installiert.

Scheme-Variable: font-build-system

Diese Variable wird vom Modul (guix build-system font) exportiert. Mit ihr steht eine Installationsprozedur für Schriftarten-Pakete zur Verfügung für vom Anbieter vorkompilierte TrueType-, OpenType- und andere Schriftartendateien, die nur an die richtige Stelle kopiert werden müssen. Dieses Erstellungssystem kopiert die Schriftartendateien an den Konventionen folgende Orte im Ausgabeverzeichnis.

Scheme-Variable: meson-build-system

Diese Variable wird vom Modul (guix build-system meson) exportiert. Sie enthält die Erstellungsprozedur für Pakete, die Meson als ihr Erstellungssystem benutzen.

Mit ihr werden sowohl Meson als auch Ninja zur Menge der Eingaben hinzugefügt; die Pakete dafür können mit den Parametern #:meson und #:ninja geändert werden, wenn nötig. Das vorgegebene Meson-Paket ist meson-for-build, ein besonderes Paket, dessen Besonderheit darin besteht, den RUNPATH von Binärdateien und Bibliotheken nicht zu entfernen, wenn sie installiert werden.

Dieses Erstellungssystem ist eine Erweiterung für das gnu-build-system, aber mit Änderungen an den folgenden Phasen, die Meson-spezifisch sind:

configure

Diese Phase führt den meson-Befehl mit den in #:configure-flags angegebenen Befehlszeilenoptionen aus. Die Befehlszeilenoption --build-type wird immer auf plain gesetzt, solange nichts anderes mit dem Parameter #:build-type angegeben wurde.

build

Diese Phase ruft ninja auf, um das Paket standardmäßig parallel zu erstellen. Die Vorgabeeinstellung, dass parallel erstellt wird, kann verändert werden durch Setzen von #:parallel-build?.

check

Diese Phase führt ninja mit dem als #:test-target spezifizierten Ziel für Tests auf, der Vorgabewert ist das Ziel namens "test".

install

Diese Phase führt ninja install aus und kann nicht verändert werden.

Dazu fügt das Erstellungssystem noch folgende neue Phasen:

fix-runpath

In dieser Phase wird sichergestellt, dass alle Binärdateien die von ihnen benötigten Bibliotheken finden können. Die benötigten Bibliotheken werden in den Unterverzeichnissen des Pakets, das erstellt wird, gesucht, und zum RUNPATH hinzugefügt, wann immer es nötig ist. Auch werden diejenigen Referenzen zu Bibliotheken aus der Erstellungsphase wieder entfernt, die bei meson-for-build hinzugefügt wurden, aber eigentlich zur Laufzeit nicht gebraucht werden, wie Abhängigkeiten nur für Tests.

glib-or-gtk-wrap

Diese Phase ist dieselbe, die auch im glib-or-gtk-build-system zur Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter #:glib-or-gtk? aktiviert werden.

glib-or-gtk-compile-schemas

Diese Phase ist dieselbe, die auch im glib-or-gtk-build-system zur Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter #:glib-or-gtk? aktiviert werden.

Scheme-Variable: linux-module-build-system

Mit linux-module-build-system können Linux-Kernelmodule erstellt werden.

Dieses Erstellungssystem ist eine Erweiterung des gnu-build-system, bei der aber die folgenden Phasen geändert wurden:

configure

Diese Phase konfiguriert die Umgebung so, dass das externe Kernel-Modul durch das Makefile des Linux-Kernels erstellt werden kann.

build

Diese Phase benutzt das Makefile des Linux-Kernels, um das externe Kernel-Modul zu erstellen.

install

Diese Phase benutzt das Makefile des Linux-Kernels zur Installation des externen Kernel-Moduls.

Es ist möglich und hilfreich, den für die Erstellung des Moduls zu benutzenden Linux-Kernel anzugeben (in der „arguments“-Form eines Pakets, dass das linux-module-build-system als Erstellungssystem benutzt, wird dazu der Schlüssel #:linux benutzt).

Scheme-Variable: node-build-system

Diese Variable wird vom Modul (guix build-system node) exportiert. Sie stellt eine Implementierung der Erstellungsprozedur von Node.js dar, die annäherungsweise der Funktion des Befehls npm install gefolgt vom Befehl npm test entspricht.

Welches Node.js-Paket zur Interpretation der npm-Befehle benutzt wird, kann mit dem Parameter #:node angegeben werden. Dessen Vorgabewert ist node.

Letztlich gibt es für die Pakete, die bei weitem nichts so komplexes brauchen, ein „triviales“ Erstellungssystem. Es ist in dem Sinn trivial, dass es praktisch keine Hilfestellungen gibt: Es fügt keine impliziten Eingaben hinzu und hat kein Konzept von Erstellungsphasen.

Scheme-Variable: trivial-build-system

Diese Variable wird vom Modul (guix build-system trivial) exportiert.

Diesem Erstellungssystem muss im Argument #:builder ein Scheme-Ausdruck übergeben werden, der die Paketausgabe(n) erstellt — wie bei build-expression->derivation (siehe build-expression->derivation).


Fußnoten

(15)

Bitte schauen Sie in den Modulen unter (guix build gnu-build-system), wenn Sie mehr Details zu Erstellungsphasen brauchen.


Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]