Erstellungssysteme (Referenzhandbuch zu GNU Guix)

8.4 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). 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.

Scheme-Variable: gnu-build-system

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:

#:phases

Mit diesem Argument wird erstellungsseitiger Code angegeben, der zu einer assoziativen Liste von Erstellungsphasen ausgewertet wird. Siehe Erstellungsphasen für nähere Informationen.

#:configure-flags

Diese Liste von Befehlszeilenoptionen (als Zeichenketten) werden dem configure-Skript übergeben. Siehe Pakete definieren für ein Beispiel.

#:make-flags

Diese 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-target

In 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.

Die Validierung besteht darin, sicherzustellen, dass jede gemeinsame Bibliothek, die von einer ELF-Binärdatei gebraucht wird (sie sind in DT_NEEDED-Einträgen im PT_DYNAMIC-Segment der ELF-Datei aufgeführt), im DT_RUNPATH-Eintrag der Datei gefunden wird. Mit anderen Worten wird gewährleistet, dass es beim Ausführen oder Benutzen einer solchen Binärdatei nicht zur Laufzeit zu einem Fehler kommt, eine Datei würde nicht gefunden. Siehe -rpath in The GNU Linker für mehr Informationen zum RUNPATH.

#: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-references

Wenn 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.

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.

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.

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 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.

Scheme-Variable: chicken-build-system

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.

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.

Wenn die Quelle einer Datei oder einem Verzeichnis ohne Schrägstrich am Ende entspricht, wird sie nach Ziel installiert.
- Hat das Ziel einen Schrägstrich am Ende, wird mit dem Basisnamen der Quelle innerhalb von Ziel installiert.
- Andernfalls wird die Quelle als Ziel installiert.
Falls es sich bei der Quelle um ein Verzeichnis mit Schrägstrich am Ende handelt oder wenn Filter benutzt werden, so ist der Schrägstrich am Ende von Ziel mit der Bedeutung wie oben implizit.
- Ohne Angabe von Filtern wird der gesamte Inhalt der Quelle nach Ziel installiert.
- Werden Filter als #: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.
  - Bei #:include werden all die Dateien installiert, deren Pfad als Suffix zu mindestens einem der Elemente der angegebenen Liste passt.
  - Bei #:include-regexp werden all die Dateien installiert, deren Unterpfad zu mindestens einem der regulären Ausdrücke in der angegebenen Liste passt.
  - Die Filter #: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.

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 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.

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 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 wird aus der Datei Project.toml ausgelesen. Durch Angabe des Arguments #:julia-package-name kann ein anderer Wert verwendet werden (die Groß-/Kleinschreibung muss stimmen).

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 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: maven-build-system

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.

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: renpy-build-system

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.

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. 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-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 debugoptimized 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).