Nächste: Erstellungsphasen, Vorige: Paketvarianten definieren, Nach oben: Programmierschnittstelle [Inhalt][Index]
Jede Paketdefinition legt ein Erstellungssystem („build system“) sowie
dessen Argumente fest (siehe Pakete definieren). Das
build-system-Feld steht für die Erstellungsprozedur des Pakets sowie
für weitere implizite Eingaben für die Erstellungsprozedur.
Erstellungssysteme sind <build-system>-Objekte. Die Schnittstelle, um
solche zu erzeugen und zu verändern, ist im Modul (guix build-system)
zu finden, und die eigentlichen Erstellungssysteme werden jeweils von ihren
eigenen Modulen exportiert.
Intern funktionieren Erstellungssysteme, indem erst Paketobjekte zu
Bags kompiliert werden. Eine Bag (deutsch: Beutel, Sack) ist wie ein
Paket, aber mit weniger Zierrat — anders gesagt ist eine Bag eine
systemnähere Darstellung eines Pakets, die sämtliche Eingaben des Pakets
einschließlich vom Erstellungssystem hinzugefügter Eingaben enthält. Diese
Zwischendarstellung wird dann zur eigentlichen Ableitung kompiliert (siehe
Ableitungen). Die Prozedur package-with-c-toolchain ist zum
Beispiel eine Möglichkeit, wie die durch das Erstellungssystem
hinzugenommenen impliziten Eingaben abgeändert werden können (siehe
package-with-c-toolchain).
Erstellungssysteme akzeptieren optional eine Liste von Argumenten. In
Paketdefinitionen werden diese über das arguments-Feld übergeben
(siehe Pakete definieren). Sie sind in der Regel
Schlüsselwort-Argumente (siehe Schlüsselwort-Argumente in Guile in Referenzhandbuch zu GNU
Guile). Der Wert dieser Argumente wird normalerweise vom Erstellungssystem
in der Erstellungsschicht ausgewertet, d.h. von einem durch den
Daemon gestarteten Guile-Prozess (siehe Ableitungen).
Das häufigste Erstellungssystem ist gnu-build-system, was die übliche
Erstellungsprozedur für GNU-Pakete und viele andere Pakete darstellt. Es
wird vom Modul (guix build-system gnu) bereitgestellt.
gnu-build-system steht für das GNU-Erstellungssystem und Varianten
desselben (siehe Konfiguration und
Makefile-Konventionen in GNU Coding Standards).
Kurz gefasst werden Pakete, die es benutzen, konfiguriert, erstellt und
installiert mit der üblichen Befehlsfolge ./configure && make && make
check && make install. In der Praxis braucht man oft noch ein paar weitere
Schritte. Alle Schritte sind in voneinander getrennte Phasen
unterteilt. Erwähnt werden sollten16:
unpackDen Quell-Tarball entpacken und das Arbeitsverzeichnis wechseln in den entpackten Quellbaum. Wenn die Quelle bereits ein Verzeichnis ist, wird es in den Quellbaum kopiert und dorthin gewechselt.
patch-source-shebangs„Shebangs“ in Quelldateien beheben, damit Sie sich auf die richtigen
Store-Dateipfade beziehen. Zum Beispiel könnte #!/bin/sh zu
#!/gnu/store/…-bash-4.3/bin/sh geändert werden.
configureDas Skript configure mit einigen vorgegebenen Befehlszeilenoptionen
ausführen, wie z.B. mit --prefix=/gnu/store/…, sowie mit den im
#:configure-flags-Argument angegebenen Optionen.
buildmake ausführen mit den Optionen aus der Liste in
#:make-flags. Wenn das Argument #:parallel-build? auf wahr
gesetzt ist (was der Vorgabewert ist), wird make -j zum Erstellen
ausgeführt.
checkmake check (oder statt check ein anderes bei
#:test-target angegebenes Ziel) ausführen, außer falls #:tests?
#f gesetzt ist. Wenn das Argument #:parallel-tests? auf wahr gesetzt
ist (der Vorgabewert), führe make check -j aus.
installmake install mit den in #:make-flags aufgelisteten Optionen
ausführen.
patch-shebangsShebangs in den installierten ausführbaren Dateien beheben.
stripSymbole zur Fehlerbehebung aus ELF-Dateien entfernen (außer
#:strip-binaries? ist auf falsch gesetzt) und in die
debug-Ausgabe kopieren, falls diese verfügbar ist (siehe
Dateien zur Fehlersuche installieren).
Das erstellungsseitige Modul (guix build gnu-build-system) definiert
%standard-phases als die vorgegebene Liste der
Erstellungsphasen. %standard-phases ist eine Liste von Paaren aus je
einem Symbol und einer Prozedur. Letztere implementiert die eigentliche
Phase.
Siehe Erstellungsphasen für weitere Informationen zu Erstellungsphasen und Möglichkeiten, diese anzupassen.
Zusätzlich stellt dieses Erstellungssystem sicher, dass die
„Standard“-Umgebung für GNU-Pakete zur Verfügung steht. Diese umfasst
Werkzeuge wie GCC, libc, Coreutils, Bash, Make, Diffutils, grep und sed
(siehe das Modul (guix build-system gnu) für eine vollständige
Liste). Wir bezeichnen sie als implizite Eingaben eines Pakets, weil
Paketdefinitionen sie nicht aufführen müssen.
Andere <build-system>-Objekte werden definiert, um andere
Konventionen und Werkzeuge von Paketen für freie Software zu
unterstützen. Die anderen Erstellungssysteme erben den Großteil vom
gnu-build-system und unterscheiden sich hauptsächlich darin, welche
Eingaben dem Erstellungsprozess implizit hinzugefügt werden und welche Liste
von Phasen durchlaufen wird. Manche dieser Erstellungssysteme sind im
Folgenden aufgeführt.
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“.
The #:main-class parameter can be used with the minimal ant buildfile
to specify the main class of the resulting jar. This makes the jar file
executable. The #:test-include parameter can be used to specify the
list of junit tests to run. It defaults to (list "**/*Test.java").
The #:test-exclude can be used to disable some tests. It defaults to
(list "**/Abstract*.java"), because abstract classes cannot be run as
tests.
Der Parameter #:build-target kann benutzt werden, um die Ant-Aufgabe
(Task) anzugeben, die während der build-Phase ausgeführt werden
soll. Vorgabe ist, dass die Aufgabe (Task) „jar“ ausgeführt wird.
Diese Variable wird von (guix build-system android-ndk)
exportiert. Sie implementiert eine Erstellungsprozedur für das Android NDK
(Native Development Kit) benutzende Pakete mit einem Guix-spezifischen
Erstellungsprozess.
Für das Erstellungssystem wird angenommen, dass Pakete die zu ihrer
öffentlichen Schnittstelle gehörenden Header-Dateien im Unterverzeichnis
include der Ausgabe out und ihre Bibliotheken im
Unterverzeichnis lib der Ausgabe out platzieren.
Ebenso wird angenommen, dass es keine im Konflikt stehenden Dateien unter der Vereinigung aller Abhängigkeiten gibt.
Derzeit wird Cross-Kompilieren hierfür nicht unterstützt, also wird dabei vorausgesetzt, dass Bibliotheken und Header-Dateien dieselben wie im Wirtssystem sind.
These variables, exported by (guix build-system asdf), implement
build procedures for Common Lisp packages using
“ASDF”. ASDF is a system
definition facility for Common Lisp programs and libraries.
The asdf-build-system/source system installs the packages in source
form, and can be loaded using any common lisp implementation, via ASDF.
The others, such as asdf-build-system/sbcl, install binary systems in
the format which a particular implementation understands. These build
systems can also be used to produce executable programs, or lisp images
which contain a set of packages pre-loaded.
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.
In order to create executable programs and images, the build-side procedures
build-program and build-image can be used. They should be
called in a build phase after the create-asdf-configuration phase, so
that the system which was just built can be used within the resulting
image. build-program requires a list of Common Lisp expressions to
be passed as the #:entry-program argument.
By default, all the .asd files present in the sources are read to
find system definitions. The #:asd-files parameter can be used to
specify the list of .asd files to read. Furthermore, if the package
defines a system for its tests in a separate file, it will be loaded before
the tests are run if it is specified by the #:test-asd-file
parameter. If it is not set, the files <system>-tests.asd,
<system>-test.asd, tests.asd, and test.asd will be
tried if they exist.
If for some reason the package must be named in a different way than the
naming conventions suggest, or if several systems must be compiled, the
#:asd-systems parameter can be used to specify the list of system
names.
Diese Variable wird vom Modul (guix build-system cargo)
exportiert. Damit können Pakete mit Cargo erstellt werden, dem
Erstellungswerkzeug der Rust-Programmiersprache.
Das Erstellungssystem fügt rustc und cargo zu den Eingaben
hinzu. Ein anderes Rust-Paket kann mit dem Parameter #:rust angegeben
werden.
Normale cargo-Abhängigkeiten sollten zur Paketdefinition über den Parameter
#:cargo-inputs als eine Liste von Paaren aus Name und Spezifikation
hinzugefügt werden, wobei als Spezifikation ein Paket oder eine
Quellcode-Definition angegeben werden kann. Beachten Sie, dass die
Spezifikation zu einem mit gzip komprimierten Tarball ausgewertet werden
muss, der eine Datei Cargo.toml in seinem Wurzelverzeichnis enthält,
ansonsten wird sie ignoriert. Analog sollten solche Abhängigkeiten, die in
cargo als „dev-dependencies“ deklariert werden, zur Paketdefinition über den
Parameter #:cargo-development-inputs hinzugefügt werden.
In seiner configure-Phase sorgt dieses Erstellungssystem dafür, dass
cargo alle Quellcodeeingaben zur Verfügung stehen, die in den Parametern
#:cargo-inputs und #:cargo-development-inputs angegeben
wurden. Außerdem wird eine enthaltene Cargo.lock-Datei entfernt,
damit cargo selbige während der build-Phase neu erzeugt. Die
install-Phase installiert die in der Crate definierten Binärdateien.
This variable is exported by (guix build-system chicken). It builds
CHICKEN Scheme modules, also called “eggs” or
“extensions”. CHICKEN generates C source code, which then gets compiled
by a C compiler, in this case GCC.
This build system adds chicken to the package inputs, as well as the
packages of gnu-build-system.
The build system can’t (yet) deduce the egg’s name automatically, so just
like with go-build-system and its #:import-path, you should
define #:egg-name in the package’s arguments field.
For example, if you are packaging the srfi-1 egg:
(arguments '(#:egg-name "srfi-1"))
Egg dependencies must be defined in propagated-inputs, not
inputs because CHICKEN doesn’t embed absolute references in compiled
eggs. Test dependencies should go to native-inputs, as usual.
Diese Variable wird vom Modul (guix build-system copy)
exportiert. Damit können einfache Pakete erstellt werden, für die nur wenig
kompiliert werden muss, sondern in erster Linie Dateien kopiert werden.
Dadurch wird ein Großteil der gnu-build-system zur Menge der
Paketeingaben hinzugefügt. Deswegen kann man bei Nutzung des
copy-build-system auf große Teile des Codes verzichten, der beim
trivial-build-system anfallen würde.
Um den Dateiinstallationsvorgang weiter zu vereinfachen, wird ein Argument
#:install-plan zur Verfügung gestellt, mit dem der Paketautor angeben
kann, welche Dateien wohin gehören. Der Installationsplan ist eine Liste aus
(Quelle Ziel [Filter]). Die Filter sind
optional.
#:include, #:include-regexp, #:exclude
oder #:exclude-regexp aufgeführt, werden je nach Filter nur die
ausgewählten Dateien installiert. Jeder Filter wird als Liste von
Zeichenketten angegeben.
#:include werden all die Dateien installiert, deren Pfad als Suffix
zu mindestens einem der Elemente der angegebenen Liste passt.
#:include-regexp werden all die Dateien installiert, deren
Unterpfad zu mindestens einem der regulären Ausdrücke in der angegebenen
Liste passt.
#:exclude und #:exclude-regexp
bewirken das Gegenteil ihrer Include-Entsprechungen. Ohne
#:include-Angaben werden alle Dateien außer den zu den
Exclude-Filtern passenden installiert. Werden sowohl #:include als
auch #:exclude angegeben, werden zuerst die #:include-Angaben
beachtet und danach wird durch #:exclude gefiltert.
In jedem Fall bleiben die Pfade relativ zur Quelle innerhalb des Ziels erhalten.
Beispiele:
("foo/bar" "share/my-app/"): Installiert bar nach share/my-app/bar.
("foo/bar" "share/my-app/baz"): Installiert bar nach share/my-app/baz.
("foo/" "share/my-app"): Installiert den Inhalt von foo innerhalb von share/my-app.
Zum Beispiel wird foo/sub/datei nach share/my-app/sub/datei
installiert.
("foo/" "share/my-app" #:include ("sub/datei")): Installiert nur foo/sub/datei
nach share/my-app/sub/datei.
("foo/sub" "share/my-app" #:include ("datei")): Installiert foo/sub/datei
nach share/my-app/datei.
Diese Variable wird durch das Modul (guix build-system clojure)
exportiert. Sie implementiert eine einfache Erstellungsprozedur für in
Clojure geschriebene Pakete mit dem guten alten
compile in Clojure. Cross-Kompilieren wird noch nicht unterstützt.
Das Erstellungssystem fügt clojure, icedtea und zip zu
den Eingaben hinzu. Sollen stattdessen andere Pakete benutzt werden, können
diese jeweils mit den Parametern #:clojure, #:jdk und
#:zip spezifiziert werden.
Eine Liste der Quellcode-Verzeichnisse, Test-Verzeichnisse und Namen der
Jar-Dateien können jeweils über die Parameter #:source-dirs,
#:test-dirs und #:jar-names angegeben werden. Das Verzeichnis,
in das kompiliert wird, sowie die Hauptklasse können jeweils mit den
Parametern #:compile-dir und #:main-class angegeben
werden. Andere Parameter sind im Folgenden dokumentiert.
Dieses Erstellungssystem ist eine Erweiterung des ant-build-system,
bei der aber die folgenden Phasen geändert wurden:
buildDiese Phase ruft compile in Clojure auf, um Quelldateien zu
kompilieren, und führt jar aus, um Jar-Dateien aus sowohl
Quelldateien als auch kompilierten Dateien zu erzeugen, entsprechend der
jeweils in #:aot-include und #:aot-exclude festgelegten Listen
aus in der Menge der Quelldateien eingeschlossenen und ausgeschlossenen
Bibliotheken. Die Ausschlussliste hat Vorrang vor der Einschlussliste. Diese
Listen setzen sich aus Symbolen zusammen, die für Clojure-Bibliotheken
stehen oder dem Schlüsselwort #:all entsprechen, was für alle im
Quellverzeichis gefundenen Clojure-Bibliotheken steht. Der Parameter
#:omit-source? entscheidet, ob Quelldateien in die Jar-Archive
aufgenommen werden sollen.
checkIn dieser Phase werden Tests auf die durch Einschluss- und Ausschlussliste
#:test-include bzw. #:test-exclude angegebenen Dateien
ausgeführt. Deren Bedeutung ist analog zu #:aot-include und
#:aot-exclude, außer dass das besondere Schlüsselwort #:all
jetzt für alle Clojure-Bibliotheken in den Test-Verzeichnissen steht. Der
Parameter #:tests? entscheidet, ob Tests ausgeführt werden sollen.
installIn dieser Phase werden alle zuvor erstellten Jar-Dateien installiert.
Zusätzlich zu den bereits angegebenen enthält dieses Erstellungssystem noch eine weitere Phase.
install-docDiese Phase installiert alle Dateien auf oberster Ebene, deren Basisnamen
ohne Verzeichnisangabe zu %doc-regex passen. Ein anderer regulärer
Ausdruck kann mit dem Parameter #:doc-regex verwendet werden. All die
so gefundenen oder (rekursiv) in den mit #:doc-dirs angegebenen
Dokumentationsverzeichnissen liegenden Dateien werden installiert.
Diese Variable wird von (guix build-system cmake) exportiert. Sie
implementiert die Erstellungsprozedur für Pakete, die das
CMake-Erstellungswerkzeug benutzen.
Das Erstellungssystem fügt automatisch das Paket cmake zu den
Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter
#:cmake geändert werden.
Der Parameter #:configure-flags wird als Liste von
Befehlszeilenoptionen aufgefasst, die an den Befehl cmake
übergeben werden. Der Parameter #:build-type abstrahiert, welche
Befehlszeilenoptionen dem Compiler übergeben werden; der Vorgabewert ist
"RelWithDebInfo" (kurz für „release mode with debugging
information“), d.h. kompiliert wird für eine Produktionsumgebung und
Informationen zur Fehlerbehebung liegen bei, was ungefähr -O2 -g
entspricht, wie bei der Vorgabe für Autoconf-basierte Pakete.
Diese Variable wird vom Modul (guix build-system dune)
exportiert. Sie unterstützt es, Pakete mit Dune
zu erstellen, einem Erstellungswerkzeug für die Programmiersprache OCaml,
und ist als Erweiterung des unten beschriebenen OCaml-Erstellungssystems
ocaml-build-system implementiert. Als solche können auch die
Parameter #:ocaml und #:findlib an dieses Erstellungssystem
übergeben werden.
Das Erstellungssystem fügt automatisch das Paket dune zu den Eingaben
hinzu. Welches Paket benutzt wird, kann mit dem Parameter #:dune
geändert werden.
Es gibt keine configure-Phase, weil dune-Pakete typischerweise nicht
konfiguriert werden müssen. Vom Parameter #:build-flags wird
erwartet, dass es sich um eine Liste von Befehlszeilenoptionen handelt, die
zur Erstellung an den dune-Befehl übergeben werden.
Der Parameter #:jbuild? kann übergeben werden, um den Befehl
jbuild anstelle des neueren dune-Befehls aufzurufen, um das
Paket zu erstellen. Der Vorgabewert ist #f.
Mit dem Parameter #:package kann ein Paketname angegeben werden, wenn
im Paket mehrere Pakete enthalten sind und nur eines davon erstellt werden
soll. Es ist äquivalent dazu, die Befehlszeilenoption -p an
dune zu übergeben.
Diese Variable wird 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.
Diese Variable wird vom Modul (guix build-system glib-or-gtk)
exportiert. Sie ist für Pakete gedacht, die GLib oder GTK benutzen.
Dieses Erstellungssystem fügt die folgenden zwei Phasen zu denen von
gnu-build-system hinzu:
glib-or-gtk-wrapDie Phase glib-or-gtk-wrap stellt sicher, dass Programme in
bin/ in der Lage sind, GLib-„Schemata“ und
GTK-Module
zu finden. Dazu wird für das Programm ein Wrapper-Skript erzeugt, dass das
eigentliche Programm mit den richtigen Werten für die Umgebungsvariablen
XDG_DATA_DIRS und GTK_PATH aufruft.
Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess
auszunehmen, indem Sie eine Liste ihrer Namen im Parameter
#:glib-or-gtk-wrap-excluded-outputs angeben. Das ist nützlich, wenn
man von einer Ausgabe weiß, dass sie keine Binärdateien enthält, die GLib
oder GTK benutzen, und diese Ausgabe durch das Wrappen ohne Not eine weitere
Abhängigkeit von GLib und GTK bekäme.
glib-or-gtk-compile-schemasMit der Phase glib-or-gtk-compile-schemas wird sichergestellt, dass
alle GSettings-Schemata für GLib kompiliert werden. Dazu wird das Programm
glib-compile-schemas ausgeführt. Es kommt aus dem Paket
glib:bin, was automatisch vom Erstellungssystem importiert
wird. Welches glib-Paket dieses glib-compile-schemas
bereitstellt, kann mit dem Parameter #:glib spezifiziert werden.
Beide Phasen finden nach der install-Phase statt.
Dieses Erstellungssystem ist für Guile-Pakete gedacht, die nur aus
Scheme-Code bestehen und so schlicht sind, dass sie nicht einmal ein
Makefile und erst recht keinen configure-Skript enthalten. Hierzu
wird Scheme-Code mit guild compile kompiliert (siehe
Compilation in Referenzhandbuch zu GNU Guile) und die
.scm- und .go-Dateien an den richtigen Pfad installiert. Auch
Dokumentation wird installiert.
Das Erstellungssystem unterstützt Cross-Kompilieren durch die Befehlszeilenoption --target für ‘guild compile’.
Mit guile-build-system erstellte Pakete müssen ein Guile-Paket in
ihrem native-inputs-Feld aufführen.
This variable is exported by (guix build-system julia). It
implements the build procedure used by julia
packages, which essentially is similar to running ‘julia -e 'using Pkg;
Pkg.add(package)'’ in an environment where JULIA_LOAD_PATH contains
the paths to all Julia package inputs. Tests are run by calling
/test/runtests.jl.
The Julia package name is read from the file Project.toml. This
value can be overridden by passing the argument #:julia-file-name
(which must be correctly capitalized).
For packages requiring shared library dependencies, you may need to write
the /deps/deps.jl file manually. It’s usually a line of const
variable = /gnu/store/library.so for each dependency, plus a void function
check_deps() = nothing.
Some older packages that aren’t using Package.toml yet, will require
this file to be created, too. The function julia-create-package-toml
helps creating the file. You need to pass the outputs and the source of the
package, it’s name (the same as the file-name parameter), the package
uuid, the package version, and a list of dependencies specified by their
name and their uuid.
Diese Variable wird vom Modul (guix build-system maven)
exportiert. Darin wird eine Erstellungsprozedur für
Maven-Pakete implementiert. Maven ist ein
Werkzeug zur Verwaltung der Abhängigkeiten und des „Lebenszyklus“ eines
Java-Projekts. Um Maven zu benutzen, werden Abhängigkeiten und Plugins in
einer Datei pom.xml angegeben, die Maven ausliest. Wenn Maven
Abhängigkeiten oder Plugins fehlen, lädt es sie herunter und erstellt damit
das Paket.
Durch Guix’ Maven-Erstellungssystem wird gewährleistet, dass Maven im Offline-Modus läuft und somit nicht versucht, Abhängigkeiten herunterzuladen. Maven wird in einen Fehler laufen, wenn eine Abhängigkeit fehlt. Bevor Maven ausgeführt wird, wird der Inhalt der pom.xml (auch in Unterprojekten) so verändert, dass darin die diejenige Version von Abhängigkeiten und Plugins aufgeführt wird, die in Guix’ Erstellungsumgebung vorliegt. Abhängigkeiten und Plugins müssen in das vorgetäuschte Maven-Repository unter lib/m2 installiert werden; bevor Maven ausgeführt wird, werden symbolische Verknüpfungen in ein echtes Repository hergestellt. Maven wird angewiesen, dieses Repository für die Erstellung zu verwenden und installiert erstellte Artefakte dorthin. Geänderte Dateien werden ins Verzeichnis lib/m2 der Paketausgabe kopiert.
Sie können eine pom.xml-Datei über das Argument #:pom-file
festlegen oder die vom Erstellungssystem vorgegebene pom.xml-Datei im
Quellverzeichnis verwenden lassen.
Sollten Sie die Version einer Abhängigkeit manuell angeben müssen, können
Sie dafür das Argument #:local-packages benutzen. Es nimmt eine
assoziative Liste entgegen, deren Schlüssel jeweils die groupId des
Pakets und deren Wert eine assoziative Liste ist, deren Schlüssel wiederum
die artifactId des Pakets und deren Wert die einzusetzende Version in
pom.xml ist.
Manche Pakete haben Abhängigkeiten oder Plugins, die weder zur Laufzeit noch
zur Erstellungszeit in Guix sinnvoll sind. Sie können sie entfernen, indem
Sie das #:exclude-Argument verwenden, um die pom.xml-Datei zu
bearbeiten. Sein Wert ist eine assoziative Liste, deren Schlüssel die
groupId des Plugins oder der Abhängigkeit ist, die Sie entfernen
möchten, und deren Wert eine Liste von zu entfernenden
artifactId-Vorkommen angibt.
Sie können statt der vorgegebenen jdk- und maven-Pakete andere
Pakete mit dem entsprechenden Argument, #:jdk bzw. #:maven,
verwenden.
Mit dem Argument #:maven-plugins geben Sie eine Liste von
Maven-Plugins zur Nutzung während der Erstellung an, im gleichen Format wie
das inputs-Feld der Paketdeklaration. Der Vorgabewert ist
(default-maven-plugins); diese Variable wird exportiert, falls Sie
sie benutzen möchten.
Diese Variable wird vom Modul (guix build-system minify)
exportiert. Sie implementiert eine Prozedur zur Minifikation einfacher
JavaScript-Pakete.
Es fügt uglify-js zur Menge der Eingaben hinzu und komprimiert damit
alle JavaScript-Dateien im src-Verzeichnis. Ein anderes Programm zur
Minifikation kann verwendet werden, indem es mit dem Parameter
#:uglify-js angegeben wird; es wird erwartet, dass das angegebene
Paket den minifizierten Code auf der Standardausgabe ausgibt.
Wenn die Eingabe-JavaScript-Dateien nicht alle im src-Verzeichnis
liegen, kann mit dem Parameter #:javascript-files eine Liste der
Dateinamen übergeben werden, auf die das Minifikationsprogramm aufgerufen
wird.
Diese Variable wird vom Modul (guix build-system ocaml)
exportiert. Mit ihr ist ein Erstellungssystem für OCaml-Pakete implementiert, was bedeutet, dass es die richtigen
auszuführenden Befehle für das jeweilige Paket auswählt. OCaml-Pakete können
sehr unterschiedliche Befehle erwarten. Dieses Erstellungssystem probiert
manche davon durch.
Wenn im Paket eine Datei setup.ml auf oberster Ebene vorhanden ist,
wird ocaml setup.ml -configure, ocaml setup.ml -build und
ocaml setup.ml -install ausgeführt. Das Erstellungssystem wird
annehmen, dass die Datei durch OASIS erzeugt wurde, und wird das Präfix setzen und Tests aktivieren, wenn
diese nicht abgeschaltet wurden. Sie können Befehlszeilenoptionen zum
Konfigurieren und Erstellen mit den Parametern #:configure-flags und
#:build-flags übergeben. Der Schlüssel #:test-flags kann
übergeben werden, um die Befehlszeilenoptionen zu ändern, mit denen die
Tests aktiviert werden. Mit dem Parameter #:use-make? kann dieses
Erstellungssystem für die build- und install-Phasen abgeschaltet werden.
Verfügt das Paket über eine configure-Datei, wird angenommen, dass
diese von Hand geschrieben wurde mit einem anderen Format für Argumente als
bei einem Skript des gnu-build-system. Sie können weitere
Befehlszeilenoptionen mit dem Schlüssel #:configure-flags hinzufügen.
Falls dem Paket ein Makefile beiliegt (oder #:use-make? auf
#t gesetzt wurde), wird dieses benutzt und weitere
Befehlszeilenoptionen können mit dem Schlüssel #:make-flags zu den
build- und install-Phasen hinzugefügt werden.
Letztlich gibt es in manchen Pakete keine solchen Dateien, sie halten sich
aber an bestimmte Konventionen, wo ihr eigenes Erstellungssystem zu finden
ist. In diesem Fall führt Guix’ OCaml-Erstellungssystem ocaml
pkg/pkg.ml oder ocaml pkg/build.ml aus und kümmert sich darum, dass
der Pfad zu dem benötigten findlib-Modul passt. Weitere
Befehlszeilenoptionen können über den Schlüssel #:build-flags
übergeben werden. Um die Installation kümmert sich
opam-installer. In diesem Fall muss das opam-Paket im
native-inputs-Feld der Paketdefinition stehen.
Beachten Sie, dass die meisten OCaml-Pakete davon ausgehen, dass sie in
dasselbe Verzeichnis wie OCaml selbst installiert werden, was wir in Guix
aber nicht so haben wollen. Solche Pakete installieren ihre
.so-Dateien in das Verzeichnis ihres Moduls, was für die meisten
anderen Einrichtungen funktioniert, weil es im OCaml-Compilerverzeichnis
liegt. Jedoch können so in Guix die Bibliotheken nicht gefunden werden,
deswegen benutzen wir CAML_LD_LIBRARY_PATH. Diese Umgebungsvariable
zeigt auf lib/ocaml/site-lib/stubslibs und dorthin sollten
.so-Bibliotheken installiert werden.
Diese Variable wird vom Modul (guix build-system python)
exportiert. Sie implementiert mehr oder weniger die konventionelle
Erstellungsprozedur, wie sie für Python-Pakete üblich ist, d.h. erst wird
python setup.py build ausgeführt und dann python setup.py
install --prefix=/gnu/store/….
Für Pakete, die eigenständige Python-Programme nach bin/
installieren, sorgt dieses Erstellungssystem dafür, dass die Programme in
ein Wrapper-Skript verpackt werden, welches die eigentlichen Programme mit
einer Umgebungsvariablen 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.
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.
This variable is exported by (guix build-system renpy). It
implements the more or less standard build procedure used by Ren’py games,
which consists of loading #:game once, thereby creating bytecode for
it.
It further creates a wrapper script in bin/ and a desktop entry in
share/applications, both of which can be used to launch the game.
Which Ren’py package is used can be specified with #:renpy. Games
can also be installed in outputs other than “out” by using
#:output.
Diese Variable wird vom Modul (guix build-system qt) exportiert. Sie
ist für Anwendungen gedacht, die Qt oder KDE benutzen.
Dieses Erstellungssystem fügt die folgenden zwei Phasen zu denen von
cmake-build-system hinzu:
check-setupDie Phase check-setup bereitet die Umgebung für Überprüfungen vor,
wie sie von Qt-Test-Programmen üblicherweise benutzt werden. Zurzeit werden
nur manche Umgebungsvariable gesetzt: QT_QPA_PLATFORM=offscreen,
DBUS_FATAL_WARNINGS=0 und CTEST_OUTPUT_ON_FAILURE=1.
Diese Phase wird vor der check-Phase hinzugefügt. Es handelt sich um
eine eigene Phase, die nach Bedarf angepasst werden kann.
qt-wrapIn der Phase qt-wrap wird nach Qt5-Plugin-Pfaden, QML-Pfaden und
manchen XDG-Daten in den Ein- und Ausgaben gesucht. Wenn solch ein Pfad
gefunden wird, werden für alle Programme in den Verzeichnissen bin/,
sbin/, libexec/ und lib/libexec/ in der Ausgabe
Wrapper-Skripte erzeugt, die die nötigen Umgebungsvariablen definieren.
Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess
auszunehmen, indem Sie eine Liste ihrer Namen im Parameter
#:qt-wrap-excluded-outputs angeben. Das ist nützlich, wenn man von
einer Ausgabe weiß, dass sie keine Qt-Binärdateien enthält, und diese
Ausgabe durch das Wrappen ohne Not eine weitere Abhängigkeit von Qt, KDE
oder Ähnlichem bekäme.
Diese Phase wird nach der install-Phase hinzugefügt.
Diese Variable wird vom Modul (guix build-system r) exportiert. Sie
entspricht einer Implementierung der durch R-Pakete genutzten Erstellungsprozedur, die wenig mehr tut, als ‘R CMD
INSTALL --library=/gnu/store/…’ in einer Umgebung auszuführen, in der die
Umgebungsvariable R_LIBS_SITE die Pfade aller R-Pakete unter den
Paketeingaben enthält. Tests werden nach der Installation mit der R-Funktion
tools::testInstalledPackage ausgeführt.
This variable is exported by (guix build-system rakudo). It
implements the build procedure used by Rakudo
for Perl6 packages. It installs the package to
/gnu/store/…/NAME-VERSION/share/perl6 and installs the
binaries, library files and the resources, as well as wrap the files under
the bin/ directory. Tests can be skipped by passing #f to the
tests? parameter.
Welches rakudo-Paket benutzt werden soll, kann mit dem Parameter
rakudo angegeben werden. Das perl6-tap-harness-Paket, das für die
Tests benutzt wird, kann mit #:prove6 ausgewählt werden; es kann auch
entfernt werden, indem man #f für den Parameter with-prove6?
übergibt. Welches perl6-zef-Paket für Tests und Installation verwendet wird,
kann mit dem Parameter #:zef angegeben werden; es kann auch entfernt
werden, indem man #f für den Parameter with-zef? übergibt.
Diese Variable wird vom Modul (guix build-system texlive)
exportiert. Mit ihr werden TeX-Pakete in Stapelverarbeitung („batch mode“)
mit der angegebenen Engine erstellt. Das Erstellungssystem setzt die
Variable TEXINPUTS so, dass alle TeX-Quelldateien unter den Eingaben
gefunden werden können.
Standardmäßig wird luatex auf allen Dateien mit der Dateiendung
ins ausgeführt. Eine andere Engine oder ein anderes Format kann mit
dem Argument #:tex-format angegeben werden. Verschiedene
Erstellungsziele können mit dem Argument #:build-targets festgelegt
werden, das eine Liste von Dateinamen erwartet. Das Erstellungssystem fügt
nur texlive-bin und texlive-latex-base zu den Eingaben hinzu
(beide kommen aus dem Modul (gnu packages tex). Für beide kann das zu
benutzende Paket jeweils mit den Argumenten #:texlive-bin oder
#:texlive-latex-base geändert werden.
Der Parameter #:tex-directory sagt dem Erstellungssystem, wohin die
installierten Dateien im texmf-Verzeichnisbaum installiert werden sollen.
Diese Variable wird vom Modul (guix build-system ruby)
exportiert. Sie steht für eine Implementierung der
RubyGems-Erstellungsprozedur, die für Ruby-Pakete benutzt wird, wobei
gem build gefolgt von gem install ausgeführt wird.
Das source-Feld eines Pakets, das dieses Erstellungssystem benutzt,
verweist typischerweise auf ein Gem-Archiv, weil Ruby-Entwickler dieses
Format benutzen, wenn sie ihre Software veröffentlichen. Das
Erstellungssystem entpackt das Gem-Archiv, spielt eventuell Patches für den
Quellcode ein, führt die Tests aus, verpackt alles wieder in ein Gem-Archiv
und installiert dieses. Neben Gem-Archiven darf das Feld auch auf
Verzeichnisse und Tarballs verweisen, damit es auch möglich ist,
unveröffentlichte Gems aus einem Git-Repository oder traditionelle
Quellcode-Veröffentlichungen zu benutzen.
Welches Ruby-Paket benutzt werden soll, kann mit dem Parameter #:ruby
festgelegt werden. Eine Liste zusätzlicher Befehlszeilenoptionen für den
Aufruf des gem-Befehls kann mit dem Parameter #:gem-flags
angegeben werden.
Diese Variable wird durch das Modul (guix build-system waf)
exportiert. Damit ist eine Erstellungsprozedur rund um das waf-Skript
implementiert. Die üblichen Phasen — configure, build und
install — sind implementiert, indem deren Namen als Argumente an das
waf-Skript übergeben werden.
Das waf-Skript wird vom Python-Interpetierer ausgeführt. Mit welchem
Python-Paket das Skript ausgeführt werden soll, kann mit dem Parameter
#:python angegeben werden.
Diese Variable wird vom Modul (guix build-system scons)
exportiert. Sie steht für eine Implementierung der Erstellungsprozedur, die
das SCons-Softwarekonstruktionswerkzeug („software construction tool“)
benutzt. Das Erstellungssystem führt scons aus, um das Paket zu
erstellen, führt mit scons test Tests aus und benutzt scons
install, um das Paket zu installieren.
Zusätzliche Optionen, die an scons übergeben werden sollen, können
mit dem Parameter #:scons-flags angegeben werden. Die
voreingestellten Erstellungs- und Installationsziele können jeweils durch
#:build-targets und #:install-targets ersetzt werden. Die
Python-Version, die benutzt werden soll, um SCons auszuführen, kann
festgelegt werden, indem das passende SCons-Paket mit dem Parameter
#:scons ausgewählt wird.
Diese Variable wird vom Modul (guix build-system haskell)
exportiert. Sie bietet Zugang zur Cabal-Erstellungsprozedur, die von
Haskell-Paketen benutzt wird, was bedeutet, runhaskell Setup.hs
configure --prefix=/gnu/store/… und runhaskell Setup.hs build
auszuführen. Statt das Paket mit dem Befehl runhaskell Setup.hs
install zu installieren, benutzt das Erstellungssystem runhaskell
Setup.hs copy gefolgt von runhaskell Setup.hs register, um keine
Bibliotheken im Store-Verzeichnis des Compilers zu speichern, auf dem keine
Schreibberechtigung besteht. Zusätzlich generiert das Erstellungssystem
Dokumentation durch Ausführen von runhaskell Setup.hs haddock, außer
#:haddock? #f wurde übergeben. Optional können an Haddock Parameter
mit Hilfe des Parameters #:haddock-flags übergeben werden. Wird die
Datei Setup.hs nicht gefunden, sucht das Erstellungssystem
stattdessen nach Setup.lhs.
Welcher Haskell-Compiler benutzt werden soll, kann über den
#:haskell-Parameter angegeben werden. Als Vorgabewert verwendet er
ghc.
Diese Variable wird vom Modul (guix build-system dub) exportiert. Sie
verweist auf eine Implementierung des Dub-Erstellungssystems, das von
D-Paketen benutzt wird. Dabei werden dub build und dub run
ausgeführt. Die Installation wird durch manuelles Kopieren der Dateien
durchgeführt.
Welcher D-Compiler benutzt wird, kann mit dem Parameter #:ldc
festgelegt werden, was als Vorgabewert ldc benutzt.
Diese Variable wird vom Modul (guix build-system emacs)
exportiert. Darin wird eine Installationsprozedur ähnlich der des
Paketsystems von Emacs selbst implementiert (siehe Packages in The GNU Emacs Manual).
Zunächst wird eine Datei Paket-autoloads.el
Diese Variable wird vom Modul (guix build-system font)
exportiert. Mit ihr steht eine Installationsprozedur für Schriftarten-Pakete
zur Verfügung für vom Anbieter vorkompilierte TrueType-, OpenType- und
andere Schriftartendateien, die nur an die richtige Stelle kopiert werden
müssen. Dieses Erstellungssystem kopiert die Schriftartendateien an den
Konventionen folgende Orte im Ausgabeverzeichnis.
Diese Variable wird vom Modul (guix build-system meson)
exportiert. Sie enthält die Erstellungsprozedur für Pakete, die
Meson als ihr Erstellungssystem benutzen.
Mit ihr werden sowohl Meson als auch Ninja
zur Menge der Eingaben hinzugefügt; die Pakete dafür können mit den
Parametern #:meson und #:ninja geändert werden, wenn
nötig. 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:
configureDiese Phase führt den meson-Befehl mit den in
#:configure-flags angegebenen Befehlszeilenoptionen aus. Die
Befehlszeilenoption --build-type wird immer auf
debugoptimized gesetzt, solange nichts anderes mit dem Parameter
#:build-type angegeben wurde.
buildDiese Phase ruft ninja auf, um das Paket standardmäßig parallel zu
erstellen. Die Vorgabeeinstellung, dass parallel erstellt wird, kann
verändert werden durch Setzen von #:parallel-build?.
checkDiese Phase führt ninja mit dem als #:test-target
spezifizierten Ziel für Tests auf, der Vorgabewert ist das Ziel namens
"test".
installDiese Phase führt ninja install aus und kann nicht verändert werden.
Dazu fügt das Erstellungssystem noch folgende neue Phasen:
fix-runpathIn dieser Phase wird sichergestellt, dass alle Binärdateien die von ihnen
benötigten Bibliotheken finden können. Die benötigten Bibliotheken werden in
den Unterverzeichnissen des Pakets, das erstellt wird, gesucht, und zum
RUNPATH hinzugefügt, wann immer es nötig ist. Auch werden diejenigen
Referenzen zu Bibliotheken aus der Erstellungsphase wieder entfernt, die bei
meson-for-build hinzugefügt wurden, aber eigentlich zur Laufzeit
nicht gebraucht werden, wie Abhängigkeiten nur für Tests.
glib-or-gtk-wrapDiese Phase ist dieselbe, die auch im glib-or-gtk-build-system zur
Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht
durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter
#:glib-or-gtk? aktiviert werden.
glib-or-gtk-compile-schemasDiese Phase ist dieselbe, die auch im glib-or-gtk-build-system zur
Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht
durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter
#:glib-or-gtk? aktiviert werden.
Mit linux-module-build-system können Linux-Kernelmodule erstellt
werden.
Dieses Erstellungssystem ist eine Erweiterung des gnu-build-system,
bei der aber die folgenden Phasen geändert wurden:
configureDiese Phase konfiguriert die Umgebung so, dass das externe Kernel-Modul durch das Makefile des Linux-Kernels erstellt werden kann.
buildDiese Phase benutzt das Makefile des Linux-Kernels, um das externe Kernel-Modul zu erstellen.
installDiese Phase benutzt das Makefile des Linux-Kernels zur Installation des externen Kernel-Moduls.
Es ist möglich und hilfreich, den für die Erstellung des Moduls zu
benutzenden Linux-Kernel anzugeben (in der arguments-Form eines
Pakets, dass das linux-module-build-system als Erstellungssystem
benutzt, wird dazu der Schlüssel #:linux benutzt).
Diese Variable wird vom Modul (guix build-system node)
exportiert. Sie stellt eine Implementierung der Erstellungsprozedur von
Node.js dar, die annäherungsweise der Funktion
des Befehls npm install gefolgt vom Befehl npm test
entspricht.
Welches Node.js-Paket zur Interpretation der npm-Befehle benutzt
wird, kann mit dem Parameter #:node angegeben werden. Dessen
Vorgabewert ist node.
Letztlich gibt es für die Pakete, die bei weitem nichts so komplexes brauchen, ein „triviales“ Erstellungssystem. Es ist in dem Sinn trivial, dass es praktisch keine Hilfestellungen gibt: Es fügt keine impliziten Eingaben hinzu und hat kein Konzept von Erstellungsphasen.
Diese Variable wird vom Modul (guix build-system trivial) exportiert.
Diesem Erstellungssystem muss im Argument #:builder ein
Scheme-Ausdruck übergeben werden, der die Paketausgabe(n) erstellt — wie bei
build-expression->derivation (siehe build-expression->derivation).
Bitte schauen Sie in den Modulen
unter (guix build gnu-build-system), wenn Sie mehr Details zu
Erstellungsphasen brauchen.
Nächste: Erstellungsphasen, Vorige: Paketvarianten definieren, Nach oben: Programmierschnittstelle [Inhalt][Index]