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


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

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

Variable: agda-build-system

Diese Variable wird vom Modul (guix build-system agda) exportiert. Sie implementiert eine Erstellungsprozedur für Agda-Bibliotheken.

Das Erstellungssystem fügt agda zu den Eingaben hinzu. Ein anderes Agda-Paket kann mit dem Schlüssel #:agda angegeben werden.

Für den Schlüssel #:plan wird eine Liste von Cons-Zellen der Form (Regexp . Parameterliste) angegeben, wobei Regexp ein regulärer Ausdruck ist, der auf die zu erstellenden .agda-Dateien passt, und Parameterliste eine Liste von Parametern sein kann, die an agda bei dessen Typprüfung übergeben werden.

Wenn die Bibliothek Haskell benutzt, um eine Datei zu erzeugen, in der alle importierten Module stehen, können Sie #:gnu-and-haskell? auf #t setzen, damit automatisch ghc und die Standardeingaben des gnu-build-system zur Liste der Eingaben hinzugefügt werden. Sie werden trotzdem von Hand eine Phase hinzufügen oder die 'build-Phase anpassen müssen, wie es in der Definition von agda-stdlib gemacht worden ist.

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.

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.

Variable: asdf-build-system/source
Variable: asdf-build-system/sbcl
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.

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.

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.

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.
    • When a package has multiple outputs, the #:output argument can be used to specify which output label the files should be installed to.

    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.
  • ("foo/doc" "share/my-app/doc" #:output "doc"): Install "foo/doc" to "share/my-app/doc" within the "doc" output.
Variable: vim-build-system

Diese Variable wird vom Modul (guix build-system vim) exportiert. Sie ist eine Erweiterung des copy-build-system, mit der Plugins für Vim und Neovim an die Stelle installiert werden, die von den beiden Texteditoren als „packpaths“ erwartet wird.

Pakete, die mit dem Präfix vim- beginnen, werden in den Packpath von Vim installiert und die, die mit dem Präfix neovim- beginnen, werden in den Packpath von Neovim installiert. Wenn ein Verzeichnis doc beim Plugin enthalten ist, werden automatisch Helptags generiert.

Für vim-build-system stehen ein paar mehr Schlüsselwörter zur Verfügung:

  • Mit plugin-name ist es möglich, den Namen des Plugins anzugeben. Vorgegeben ist hierfür der Name und die Version des Pakets, aber hilfreicher ist, den Namen anzugeben, der vom Autor beim Anbieter für das Plugin hinterlegt wurde. Dieser Name ist der, den Sie in Vim für :packadd benutzen.
  • With install-plan it is possible to augment the built-in install-plan of the vim-build-system. This is particularly helpful if you have files which should be installed in other locations. For more information about using the install-plan, see the copy-build-system (siehe copy-build-system).
  • With #:vim it is possible to add this package to Vim’s packpath, in addition to if it is added automatically because of the vim- prefix in the package’s name.
  • With #:neovim it is possible to add this package to Neovim’s packpath, in addition to if it is added automatically because of the neovim- prefix in the package’s name.
  • With #:mode it is possible to adjust the path which the plugin is installed into. By default the plugin is installed into start and other options are available, including opt. Adding a plugin into opt will mean you will need to run, for example, :packadd foo to load the foo plugin from inside of Vim.
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.

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 Produktivumgebung und Informationen zur Fehlerbehebung liegen bei, was ungefähr -O2 -g entspricht, wie bei der Vorgabe für Autoconf-basierte Pakete.

Variable: composer-build-system

Diese Variable wird von (guix build-system composer) exportiert. Sie implementiert die Erstellungsprozedur für Pakete, die auf die PHP-Paketverwaltung Composer zugeschnitten sind.

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

Mit dem Parameter #:test-target stellen Sie ein, welcher Skript die Tests laufen lässt. Vorgegeben ist, den Skript test zu starten, wenn er existiert. Wenn der Skript nicht existiert, wird durch das Erstellungssystem phpunit im Quellverzeichnis ausgeführt, sofern eine Datei phpunit.xml existiert.

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.

Variable: elm-build-system

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:

  • Der Fokus für das Erstellungssystem liegt auf dem, was in Elm Pakete genannt wird, also auf Projekten in Elm, für die { "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).
  • In Elm können mehrere Versionen desselben Pakets nebeneinander unter 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.
  • Wir sind noch nicht so weit, dass wir den Testkatalog für Elm-Projekte durchlaufen lassen könnten, weil es in Guix weder ein Paket für elm-test-rs noch für den Node.js-basierten elm-test gibt, um Testläufe durchzuführen.
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.

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.

Nach dem Schlüsselwort #:go kann festgelegt werden, mit welchem Go-Compiler-Paket das Paket erstellt werden soll.

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.

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.

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 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") "\")\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.

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.

Variable: minetest-mod-build-system

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.

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.

Variable: mozilla-build-system

Diese Variable wird vom Modul (guix build-system mozilla) exportiert. Durch Sie werden die configure-Befehlszeilenoptionen --target und --host so verwendet, wie es bei von Mozilla entwickelter Software erwartet wird – aus historischen Gründen wird bei Mozilla-Software für --host das System verlangt, von dem aus cross-kompiliert wird, und für --target das System, für das cross-kompiliert wird, entgegen der bei Autotools üblichen Konvention.

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.

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

Variable: pyproject-build-system

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.

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.

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.

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.

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.

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.

Variable: rebar-build-system

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:

unpack

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

bootstrap
configure

Die Phasen bootstrap und configure fehlen, weil Erlang-Pakete normalerweise nicht konfiguriert werden müssen.

build

In dieser Phase wird rebar3 compile mit den Befehlszeilenoptionen aus #:rebar-flags ausgeführt.

check

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

install

Hier werden die im standardmäßigen Profil default erzeugten Dateien installiert oder die aus einem mit #:install-profile angegebenen anderen Profil.

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 versucht, luatex auf allen Dateien mit der Dateiendung .ins auszuführen, und wenn keine gefunden werden, wird es auf allen .dtx-Dateien ausgeführt. Eine andere Engine oder ein anderes Format kann mit dem Argument #:tex-engine bzw. #:tex-format angegeben werden. Verschiedene Erstellungsziele können mit dem Argument #:build-targets festgelegt werden, das eine Liste von Dateinamen erwartet.

Es werden außerdem Font-Metriken (d.h. .tfm-Dateien) aus Metafont-Dateien erzeugt, wenn möglich. Auch können formatierte Dateien für TeX (d.h. .fmt-Dateien) erzeugt werden, die im Argument #:create-formats aufzulisten sind, und es wird je eine symbolische Verknüpfung im bin/-Verzeichnis zu in texmf-dist/scripts/ befindlichen Skripts angelegt, wenn der Name der Datei im Argument #:link-scripts aufgelistet ist.

Das Erstellungssystem fügt texlive-bin aus dem Modul (gnu packages tex) zu den nativen Eingaben hinzu. Das zu benutzende Paket kann mit dem Argument #:texlive-bin geändert werden.

Das Paket texlive-latex-bin aus demselben Modul enthält den Großteil der Werkzeuge zum Erstellen von TeX-Live-Paketen; weil es praktisch ist, wird es auch in der Vorgabeeinstellung zu den nativen Eingaben hinzugefügt. Das kann jedoch störend sein, wenn eine Abhängigkeit von texlive-latex-bin selbst erstellt wird. In diesem speziellen Fall sollten Sie das Argument #:texlive-latex-bin? auf #f setzen.

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.

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.

Variable: zig-build-system

Diese Variable wird von (guix build-system zig) exportiert. Sie implementiert die Erstellungsprozeduren für Pakete, die das für Zig vorgesehene Erstellungssystem (den Befehl zig build) benutzen.

Dieses Erstellungssystem fügt zig neben den Paketen des gnu-build-system zu den Paketeingaben hinzu.

Es gibt keine configure-Phase, weil Zig-Pakete typischerweise nicht konfiguriert werden müssen. Für den Parameter #:zig-build-flags geben Sie eine Liste von Befehlszeilenoptionen an, die zur Erstellung an den Befehl zig übergeben werden. Für den Parameter #:zig-test-flags geben Sie eine Liste von Befehlszeilenoptionen an, die während der check-Phase an den Befehl zig test übergeben werden. Sie können einen anderen Compiler als vorgegeben verwenden, indem Sie das Argument #:zig angeben.

Mit dem optionalen Parameter zig-release-type deklarieren Sie, für welche Art von Release optimiert wird. Diese Werte sind möglich: safe (sicher), fast (schnell) oder small (klein). Vorgegeben ist der Wert #f, durch den kein Release als Befehlszeilenoption an den zig-Befehl übergeben wird. Dadurch wird eine debug-Version zur Fehlersuche erstellt.

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.

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.

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.

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.

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.

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.

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

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

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

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

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.

Variable: tree-sitter-build-system

Diese Variable wird vom Modul (guix build-system tree-sitter) exportiert. Sie implementiert, wie Grammatiken für Tree-sitter, einer Bibliothek zur Syntaxanalyse, kompiliert werden. Dazu wird hauptsächlich tree-sitter generate ausgeführt, um Grammatiken in grammar.js-Dateien nach JSON und anschließend nach C zu übersetzen. Daraus wird dann Maschinencode kompiliert.

Tree-sitter-Pakete können mehrere Grammatiken enthalten. Deswegen ermöglicht es dieses Erstellungssystem, mit einem Schlüsselwort #:grammar-directories eine Liste von Orten anzugeben, wo je eine grammar.js zu finden ist.

In manchen Fällen hängt die eine Grammatik von der anderen ab, etwa wenn C++ von C abhängt oder TypeScript von JavaScript. Solche Abhängigkeiten können Sie als Eingaben unter #:inputs angeben.

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.

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

Variable: channel-build-system

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.

Optional kann ein #:channels-Argument mit zusätzlichen Kanälen angegeben werden.

Damit ergit sich ein Paket mit einer Guix-Instanz der angegebenen Kanäle, ähnlich der, die guix time-machine erstellen würde.


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