Nächste: Erstellungsphasen, Vorige: Manifeste verfassen, Nach oben: Programmierschnittstelle [Inhalt][Index]
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). Die Prozedur package-with-c-toolchain ist zum
Beispiel eine Möglichkeit, wie die durch das Erstellungssystem
hinzugenommenen impliziten Eingaben abgeändert werden können (siehe
package-with-c-toolchain).
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 Schlüsselwort-Argumente in Guile in Referenzhandbuch zu GNU
Guile). 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.
gnu-build-system steht für das GNU-Erstellungssystem und Varianten
desselben (siehe Konfiguration und
Makefile-Konventionen 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. Siehe Erstellungsphasen für mehr Informationen zu
Erstellungsphasen und wie man sie anpassen kann.
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.
Dieses Erstellungssystem unterstützt eine Reihe von Schlüsselwortargumenten,
die über das arguments-Feld eines Pakets übergeben werden
können. Hier sind einige der wichtigen Parameter:
#:phasesMit diesem Argument wird erstellungsseitiger Code angegeben, der zu einer assoziativen Liste von Erstellungsphasen ausgewertet wird. Siehe Erstellungsphasen für nähere Informationen.
#:configure-flagsDiese Liste von Befehlszeilenoptionen (als Zeichenketten) werden dem
configure-Skript übergeben. Siehe Pakete definieren für ein
Beispiel.
#:make-flagsDiese Zeichenkettenliste enthält Befehlszeilenoptionen, die als Argumente an
make-Aufrufe in den Phasen build, check und
install übergeben werden.
#:out-of-source?Dieser Boolesche Ausdruck, nach Vorgabe steht er auf #f, zeigt an, ob
Erstellungen in einem gesonderten Erstellungsverzeichnis abseits des
Quellbaums ausgeführt werden sollen.
Wenn es auf wahr steht, wird in der configure-Phase eigens ein
Erstellungsverzeichnis angelegt, dorthin gewechselt und das
configure-Skript von dort ausgeführt. Das ist nützlich bei Paketen,
die so etwas voraussetzen, wie glibc.
#:tests?Dieser Boolesche Ausdruck, nach Vorgabe steht er auf #t, zeigt an, ob
in der check-Phase der Testkatalog des Pakets ausgeführt werden soll.
#:test-targetIn dieser Zeichenkette, nach Vorgabe "check", wird der Name des
Makefile-Ziels angegeben, das die check-Phase benutzt.
#:parallel-build?#:parallel-tests?Mit diesen Booleschen Werten wird festgelegt, ob die Erstellung respektive
der Testkatalog parallel ausgeführt werden soll, indem die
Befehlszeilenoption -j an make übergeben wird. Wenn die
Werte wahr sind, wird an make die Option -jn übergeben,
wobei n die Zahl ist, die in der --cores-Befehlszeilenoption
an guix-daemon oder an den guix-Clientbefehl übergeben
wurde (siehe --cores).
#:validate-runpath?Dieser Boolesche Ausdruck, nach Vorgabe #t, bestimmt, ob der in
ELF-Binärdateien, die in der install-Phase installiert worden sind,
eingetragene RUNPATH „validiert“ werden soll. ELF-Binärdateien sind
gemeinsame Bibliotheken („Shared Libraries“ mit Dateiendung .so)
sowie ausführbare Dateien. Siehe die Phase
validate-runpath für die Details.
#:substitutable?Dieser Boolesche Ausdruck, nach Vorgabe #t, sagt aus, ob
Paketausgaben substituierbar sein sollen, d.h. ob Benutzer Substitute
dafür beziehen können sollen, statt sie lokal erstellen zu müssen (siehe
Substitute).
#:allowed-references#:disallowed-referencesWenn für diese Argumente ein wahrer Wert angegeben wird, muss er einer Liste von Abhängigkeiten entsprechen, die nicht unter den Referenzen der Erstellungsergebnisse vorkommen dürfen. Wenn nach dem Ende der Erstellung eine solche Referenz noch vorhanden ist, schlägt der Erstellungsvorgang fehl.
Sie eignen sich, um zu garantieren, dass ein Paket nicht fälschlich seine Abhängigkeiten aus der Erstellungszeit weiter referenziert, wenn das, zum Beispiel, die Größe unnötig in die Höhe treiben würde.
Auch die meisten anderen Erstellungssysteme unterstützen diese Schlüsselwortargumente.
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.
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.
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.
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.
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-asdf-configuration-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.
Vorgegeben ist, alle .asd-Dateien im Quellverzeichnis zu lesen, um zu
ermitteln, welche Systeme definiert sind. Mit dem Parameter
#:asd-files kann die Liste zu lesender .asd-Dateien festgelegt
werden. 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 oder wenn mehrere Systeme kompiliert werden, kann der Parameter
#:asd-systems benutzt werden, um die Liste der Systemnamen anzugeben.
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 so wie bei anderen Paketen in die
Paketdefinition eingetragen werden; wenn sie nur zur Erstellungszeit
gebraucht werden, gehören sie in native-inputs, sonst in
inputs. Wenn die Abhängigkeiten Crates sind, die nur als Quellcode
vorliegen, sollten sie zusätzlich über den Parameter #:cargo-inputs
als eine Liste von Paaren aus Name und Spezifikation hinzugefügt, 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
package-Phase führt cargo package aus, um eine Quellcode-Crate
zur späteren Nutzung zu erzeugen. Die install-Phase installiert die
in der Crate definierten Binärdateien. Wenn nicht
install-source? #f definiert ist, werden auch ein Verzeichnis mit dem
eigenen Quellcode in einer Crate und auch der unverpackte Quellcode
installiert, damit es leichter ist, später an Rust-Paketen zu hacken.
Diese Variable wird von (guix build-system chicken) exportiert. Mit
ihr werden Module von CHICKEN Scheme
kompiliert. Sie sind auch bekannt als „Eggs“ oder als
„Erweiterungen“. CHICKEN erzeugt C-Quellcode, der dann von einem C-Compiler
kompiliert wird; in diesem Fall vom GCC.
Dieses Erstellungssystem fügt chicken neben den Paketen des
gnu-build-system zu den Paketeingaben hinzu.
Das Erstellungssystem kann den Namen des Eggs (noch) nicht automatisch
herausfinden, also müssen Sie, ähnlich wie beim #:import-path des
go-build-system, im arguments-Feld des Pakets den
#:egg-name festlegen.
Zum Beispiel würden Sie so vorgehen, um ein Paket für das Egg srfi-1
zu schreiben:
(arguments '(#:egg-name "srfi-1"))
Abhängigkeiten von Eggs müssen in propagated-inputs genannt werden
und nicht in inputs, weil CHICKEN keine absoluten Referenzen
in kompilierte Eggs einbettet. Abhängigkeiten für Tests sollten wie üblich
in native-inputs stehen.
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.
#:include, #:include-regexp, #:exclude
oder #:exclude-regexp aufgeführt, werden je nach Filter nur die
ausgewählten Dateien installiert. Jeder Filter wird als Liste von
Zeichenketten angegeben.
#:include werden all die Dateien installiert, deren Pfad als Suffix
zu mindestens einem der Elemente der angegebenen Liste passt.
#:include-regexp werden all die Dateien installiert, deren
Unterpfad zu mindestens einem der regulären Ausdrücke in der angegebenen
Liste passt.
#:exclude und #:exclude-regexp
bewirken das Gegenteil ihrer Include-Entsprechungen. Ohne
#:include-Angaben werden alle Dateien außer den zu den
Exclude-Filtern passenden installiert. Werden sowohl #:include als
auch #:exclude angegeben, werden zuerst die #:include-Angaben
beachtet und danach wird durch #:exclude gefiltert.
In jedem Fall bleiben die Pfade relativ zur Quelle innerhalb des Ziels erhalten.
Beispiele:
("foo/bar" "share/my-app/"): Installiert bar nach share/my-app/bar.
("foo/bar" "share/my-app/baz"): Installiert bar nach share/my-app/baz.
("foo/" "share/my-app"): Installiert den Inhalt von foo innerhalb von share/my-app.
Zum Beispiel wird foo/sub/datei nach share/my-app/sub/datei
installiert.
("foo/" "share/my-app" #:include ("sub/datei")): Installiert nur foo/sub/datei
nach share/my-app/sub/datei.
("foo/sub" "share/my-app" #:include ("datei")): Installiert foo/sub/datei
nach share/my-app/datei.
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:
buildDiese 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.
checkIn 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.
installIn dieser Phase werden alle zuvor erstellten Jar-Dateien installiert.
Zusätzlich zu den bereits angegebenen enthält dieses Erstellungssystem noch eine weitere Phase.
install-docDiese 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.
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.
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.
Diese Variable wird von (guix build-system elm) exportiert. Sie
implementiert eine Erstellungsprozedur für Elm-Pakete ähnlich wie ‘elm install’.
Mit dem Erstellungssystem wird ein Elm-Compiler-Paket zu der Menge der
Eingaben hinzugefügt. Anstelle des vorgegebenen Compiler-Pakets (derzeit ist
es elm-sans-reactor) kann das stattdessen zu verwendende
Compiler-Paket im Argument #:elm angegeben werden. Zudem werden
Elm-Pakete, die vom Erstellungssystem selbst vorausgesetzt werden, als
implizite Eingaben hinzugefügt, wenn sie noch keine sind; wenn Sie das
verhindern möchten, übergeben Sie das Argument
#:implicit-elm-package-inputs?, was in erster Linie zum Bootstrapping
gebraucht wird.
Die Einträge für "dependencies" und "test-dependencies" in der
Datei elm.json eines Elm-Pakets werden jeweils mit
propagated-inputs bzw. inputs wiedergegeben.
In Elm wird von Paketnamen eine bestimmte Struktur verlangt. Siehe Elm-Pakete für mehr Details auch zu den Werkzeugen in (guix
build-system elm), um damit umzugehen.
Derzeit gelten für elm-build-system ein paar nennenswerte
Einschränkungen:
{ "type":
"package" } in deren elm.json-Dateien deklariert wurde. Wenn jemand
mit elm-build-system Elm-Anwendungen erstellen möchte (für die
{ "type": "application" } deklariert wurde), ist das möglich, aber
es müssen eigens Änderungen an den Erstellungsphasen vorgenommen
werden. Beispiele sind in den Definitionen der Beispielanwendung
elm-todomvc und im elm-Paket selbst zu finden (weil die
Web-Oberfläche des Befehls ‘elm reactor’ eine Elm-Anwendung ist).
ELM_HOME vorkommen, aber mit elm-build-system klappt das noch
nicht so gut. Diese Einschränkung gilt vor allem für Elm-Anwendungen, weil
dort die Versionen ihrer Abhängigkeiten genau festgelegt werden, während
Elm-Pakete mit einem Bereich von Versionen umgehen können. Ein Ausweg wird
in der oben genannten Beispielanwendung genommen, nämlich benutzt sie die
Prozedur patch-application-dependencies aus (guix build
elm-build-system), um die elm.json-Dateien umzuschreiben, damit sie
sich stattdessen auf die Paketversionen beziehen, die es in der
Erstellungsumgebung tatsächlich gibt. Alternativ könnte man auch auf
Guix-Paketumwandlungen zurückgreifen (siehe Paketvarianten definieren), um den gesamten Abhängigkeitsgraphen einer Anwendung
umzuschreiben.
elm-test-rs noch
für den Node.js-basierten
elm-test
gibt, um Testläufe durchzuführen.
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.
Cross-Erstellungen von Paketen sind möglich. Wenn für eine bestimmte
Architektur oder ein bestimmtes Betriebssystem erstellt werden muss, kann
man mit den Schlüsselwörtern #:goarch und #:goos erzwingen,
dass das Paket für diese Architektur und dieses Betriebssystem erstellt
wird. Die für Go nutzbaren Kombinationen sind
in der
Go-Dokumentation nachlesbar.
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-wrapDie 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-schemasMit 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.
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 Referenzhandbuch zu GNU Guile) 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.
Diese Variable wird vom Modul (guix build-system julia)
exportiert. Sie entspricht einer Implementierung der durch
Julia-Pakete genutzten Erstellungsprozedur
und verhält sich im Prinzip so, wie wenn man ‘julia -e 'using Pkg;
Pkg.add(paket)'’ in einer Umgebung ausführt, in der die Umgebungsvariable
JULIA_LOAD_PATH die Pfade aller Julia-Pakete unter den Paketeingaben
enthält. Tests werden durch Aufruf von /test/runtests.jl ausgeführt.
Der Name des Julia-Pakets und seine UUID werden aus der Datei
Project.toml ausgelesen. Durch Angabe des Arguments
#:julia-package-name (die Groß-/Kleinschreibung muss stimmen) bzw.
durch #:julia-package-uuid können andere Werte verwendet werden.
Julia-Pakete verwalten ihre Abhängigkeiten zu Binärdateien für gewöhnlich
mittels JLLWrappers.jl, einem Julia-Paket, das ein Modul erzeugt
(benannt nach der Bibliothek, die zugänglich gemacht wird, gefolgt von
_jll.jl).
Um die _jll.jl-Pakete mit den Pfaden zu Binärdateien hinzuzufügen,
müssen Sie die Dateien in src/wrappers/ patchen, um dem Aufruf an das
Makro JLLWrappers.@generate_wrapper_header noch ein zweites Argument
mit dem Store-Pfad der Binärdatei mitzugeben.
Zum Beispiel fügen wir für das MbedTLS-Julia-Paket eine Erstellungsphase hinzu (siehe Erstellungsphasen), in der der absolute Dateiname des zugänglich gemachten MbedTLS-Pakets hinzugefügt wird:
(add-after 'unpack 'override-binary-path
(lambda* (#:key inputs #:allow-other-keys)
(for-each (lambda (wrapper)
(substitute* wrapper
(("generate_wrapper_header.*")
(string-append
"generate_wrapper_header(\"MbedTLS\", \""
(assoc-ref inputs "mbedtls-apache") "\")\n"))))
;; Es gibt eine Julia-Datei für jede Plattform,
;; wir ändern sie alle.
(find-files "src/wrappers/" "\\.jl$"))))
Für manche ältere Pakete, die noch keine Project.toml benutzen, muss
auch diese Datei erstellt werden. Das geht intern vonstatten, sofern die
Argumente #:julia-package-name und #:julia-package-uuid
übergeben werden.
Diese Variable wird vom Modul (guix build-system maven)
exportiert. Darin wird eine Erstellungsprozedur für
Maven-Pakete implementiert. Maven ist ein
Werkzeug zur Verwaltung der Abhängigkeiten und des „Lebenszyklus“ eines
Java-Projekts. Um Maven zu benutzen, werden Abhängigkeiten und Plugins in
einer Datei pom.xml angegeben, die Maven ausliest. Wenn Maven
Abhängigkeiten oder Plugins fehlen, lädt es sie herunter und erstellt damit
das Paket.
Durch Guix’ Maven-Erstellungssystem wird gewährleistet, dass Maven im Offline-Modus läuft und somit nicht versucht, Abhängigkeiten herunterzuladen. Maven wird in einen Fehler laufen, wenn eine Abhängigkeit fehlt. Bevor Maven ausgeführt wird, wird der Inhalt der pom.xml (auch in Unterprojekten) so verändert, dass darin die diejenige Version von Abhängigkeiten und Plugins aufgeführt wird, die in Guix’ Erstellungsumgebung vorliegt. Abhängigkeiten und Plugins müssen in das vorgetäuschte Maven-Repository unter lib/m2 installiert werden; bevor Maven ausgeführt wird, werden symbolische Verknüpfungen in ein echtes Repository hergestellt. Maven wird angewiesen, dieses Repository für die Erstellung zu verwenden und installiert erstellte Artefakte dorthin. Geänderte Dateien werden ins Verzeichnis lib/m2 der Paketausgabe kopiert.
Sie können eine pom.xml-Datei über das Argument #:pom-file
festlegen oder die vom Erstellungssystem vorgegebene pom.xml-Datei im
Quellverzeichnis verwenden lassen.
Sollten Sie die Version einer Abhängigkeit manuell angeben müssen, können
Sie dafür das Argument #:local-packages benutzen. Es nimmt eine
assoziative Liste entgegen, deren Schlüssel jeweils die groupId des
Pakets und deren Wert eine assoziative Liste ist, deren Schlüssel wiederum
die artifactId des Pakets und deren Wert die einzusetzende Version in
pom.xml ist.
Manche Pakete haben Abhängigkeiten oder Plugins, die weder zur Laufzeit noch
zur Erstellungszeit in Guix sinnvoll sind. Sie können sie entfernen, indem
Sie das #:exclude-Argument verwenden, um die pom.xml-Datei zu
bearbeiten. Sein Wert ist eine assoziative Liste, deren Schlüssel die
groupId des Plugins oder der Abhängigkeit ist, die Sie entfernen
möchten, und deren Wert eine Liste von zu entfernenden
artifactId-Vorkommen angibt.
Sie können statt der vorgegebenen jdk- und maven-Pakete andere
Pakete mit dem entsprechenden Argument, #:jdk bzw. #:maven,
verwenden.
Mit dem Argument #:maven-plugins geben Sie eine Liste von
Maven-Plugins zur Nutzung während der Erstellung an, im gleichen Format wie
das inputs-Feld der Paketdeklaration. Der Vorgabewert ist
(default-maven-plugins); diese Variable wird exportiert, falls Sie
sie benutzen möchten.
Diese Variable wird vom Modul (guix build-system minetest)
exportiert. Mit ihr ist ein Erstellungssystem für Mods für
Minetest implementiert, was bedeutet,
Lua-Code, Bilder und andere Ressourcen an den Ort zu kopieren, wo Minetest
nach Mods sucht. Das Erstellungssystem verkleinert auch PNG-Bilder und
prüft, dass Minetest die Mod fehlerfrei laden kann.
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.
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.
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 GUIX_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.
Wenn eine der Ausgaben "python" heißt, wird das Paket dort hinein
installiert und nicht in die vorgegebene Ausgabe "out". Das
ist für Pakete gedacht, bei denen ein Python-Paket nur einen Teil der
Software ausmacht, man also die Phasen des python-build-system mit
einem anderen Erstellungssystem zusammen verwenden wollen könnte. Oft kann
man das bei Anbindungen für Python gebrauchen.
Diese Variable wird vom Modul guix build-system pyproject
exportiert. Es basiert auf python-build-system und fügt Unterstützung
für pyproject.toml und PEP
517 hinzu. Auch kommt Unterstützung für verschiedene Build Backends und
Testrahmen hinzu.
Die Programmierschnittstelle unterscheidet sich leicht von python-build-system:
#:use-setuptools? und #:test-target wurden entfernt.
#:build-backend ist neu. Die Vorgabe dafür ist #false, so dass
das richtige Backend wenn möglich aufgrund von pyproject.toml
bestimmt wird.
#:test-backend ist neu. Die Vorgabe dafür ist #false, so dass
das richtige Test-Backend wenn möglich aufgrund der Paketeingaben gewählt
wird.
#:test-flags ist neu. Vorgegeben ist '(). Die Optionen darin
werden als Befehlszeilenargumente an den Test-Befehl übermittelt. Beachten
Sie, dass ausführliche Ausgaben immer aktiviert werden, falls dies für das
Backend implementiert ist.
Wir stufen es als „experimentell“ ein, weil die Details der Implementierung noch nicht in Stein gemeißelt sind. Dennoch würden wir es begrüßen, wenn Sie es für neue Python-Projekte verwenden (auch für solche, die setup.py haben). Die Programmierschnittstelle wird sich noch ändern, aber wir werden uns um im Guix-Kanal aufkommende Probleme kümmern.
Schlussendlich wird dieses Erstellungssystem für veraltet erklärt werden und in python-build-system aufgehen, wahrscheinlich irgendwann im Jahr 2024.
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.
Diese Variable wird vom Modul (guix build-system renpy)
exportiert. Sie implementiert mehr oder weniger die herkömmliche
Erstellungsprozedur, die für Ren’py-Spiele benutzt wird. Das bedeutet, das
#:game wird einmal geladen, wodurch Bytecode dafür erzeugt wird.
Des Weiteren wird ein Wrapper-Skript in bin/ und eine *.desktop-Datei
in share/applications erzeugt. Mit beiden davon kann man das Spiel
starten.
Welches Ren’py-Paket benutzt wird, gibt man mit #:renpy an. Spiele
können auch in andere Ausgaben als in „out“ installiert werden, indem man
#:output benutzt.
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-setupDie Phase check-setup bereitet die Umgebung für Überprüfungen vor,
wie sie von Qt-Test-Programmen üblicherweise benutzt werden. Zurzeit 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-wrapIn 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.
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.
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.
Diese Variable wird von (guix build-system rebar) exportiert. Sie
implementiert eine Erstellungsprozedur, die auf
rebar3 aufbaut, einem Erstellungssystem für
Programme, die in der Sprache Erlang geschrieben sind.
Das Erstellungssystem fügt sowohl rebar3 als auch erlang zu
den Eingaben hinzu. Sollen stattdessen andere Pakete benutzt werden, können
diese jeweils mit den Parametern #:rebar und #:erlang
spezifiziert werden.
Dieses Erstellungssystem basiert auf gnu-build-system, bei dem aber
die folgenden Phasen geändert wurden:
unpackDiese Phase entpackt die Quelle wie es auch das gnu-build-system tut,
schaut nach einer Datei contents.tar.gz auf der obersten Ebene des
Quellbaumes und wenn diese existiert, wird auch sie entpackt. Das
erleichtert den Umgang mit Paketen, die auf https://hex.pm/, der
Paketsammlung für Erlang und Elixir, angeboten werden.
bootstrapconfigureDie Phasen bootstrap und configure fehlen, weil Erlang-Pakete
normalerweise nicht konfiguriert werden müssen.
buildIn dieser Phase wird rebar3 compile mit den Befehlszeilenoptionen aus
#:rebar-flags ausgeführt.
checkSofern nicht #:tests? #f übergeben wird, wird in dieser Phase
rebar3 eunit ausgeführt oder das Gleiche auf ein anderes bei
#:test-target angegebenes Ziel. Dabei werden die
Befehlszeilenoptionen aus #:rebar-flags übergeben.
installHier werden die im standardmäßigen Profil default erzeugten Dateien
installiert oder die aus einem mit #:install-profile angegebenen
anderen Profil.
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.
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.
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.
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.
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.
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.
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
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.
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.
Dieses Erstellungssystem ist eine Erweiterung für das
gnu-build-system, aber mit Änderungen an den folgenden Phasen, die
Meson-spezifisch sind:
configureDiese Phase führt den meson-Befehl mit den in
#:configure-flags angegebenen Befehlszeilenoptionen aus. Die
Befehlszeilenoption --build-type wird immer auf
debugoptimized gesetzt, solange nichts anderes mit dem Parameter
#:build-type angegeben wurde.
buildDiese 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?.
checkDie Phase führt ‘meson test’ mit einer unveränderlichen Grundmenge von
Optionen aus. Diese Grundmenge können Sie mit dem Argument
#:test-options erweitern, um zum Beispiel einen bestimmten
Testkatalog auszuwählen oder zu überspringen.
installDiese Phase führt ninja install aus und kann nicht verändert werden.
Dazu fügt das Erstellungssystem noch folgende neue Phasen:
fix-runpathIn 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 hinzugefügt wurden, aber eigentlich zur Laufzeit nicht
gebraucht werden, wie Abhängigkeiten nur für Tests.
glib-or-gtk-wrapDiese 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-schemasDiese 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.
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:
configureDiese Phase konfiguriert die Umgebung so, dass das externe Kernel-Modul durch das Makefile des Linux-Kernels erstellt werden kann.
buildDiese Phase benutzt das Makefile des Linux-Kernels, um das externe Kernel-Modul zu erstellen.
installDiese 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).
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.
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).
Diese Variable wird vom Modul (guix build-system channel) exportiert.
Dieses Erstellungssystem ist in erster Linie auf interne Nutzung
ausgelegt. Ein Paket mit diesem Erstellungssystem muss im source-Feld
eine Kanalspezifikation stehen haben (siehe Kanäle); alternativ kann
für source der Name eines Verzeichnisses angegeben werden, dann muss
aber ein Argument #:commit mit dem gewünschten Commit (einer
hexadezimalen Zeichenkette) übergeben werden, so dass dieser erstellt wird.
Damit ergit sich ein Paket mit einer Guix-Instanz des angegebenen Kanals,
ähnlich der, die guix time-machine erstellen würde.
Nächste: Erstellungsphasen, Vorige: Manifeste verfassen, Nach oben: Programmierschnittstelle [Inhalt][Index]