GNU Build System

Das GNU Build System ist eine Sammlung von Tools für die Programmierung, die vom GNU-Projekt entwickelt wurden. Diese Tools sind für das Portieren von Quellcode-Paketen auf Unix-Systemen gedacht. Das GNU Build System ist Teil der GNU Toolchains und ist in freien Software-Projekten weit verbreitet. Während die Werkzeuge selbst freie Software sind und unter der GPL stehen, können auch proprietäre Projekte damit entwickelt werden.

Enthaltene Werkzeuge

Das GNU Build System wird durch die sogenannten Autotools erstellt^[1]. Autotools enthält die GNU-Werkzeuge Autoconf, Autoheader, Automake und Libtool. Weitere ähnliche Programme, die oftmals zusammen mit dem GNU Build System genutzt werden, sind GNU Make, GNU gettext, pkg-config und die GNU Compiler Collection, auch unter der Bezeichnung GCC bekannt.

GNU Autoconf

Autoconf ist eine Software, die automatisch Shell-Skripte generiert, die wiederum Makefiles für ein Softwarepaket erstellen, um das Übersetzen des Quellcodes für verschiedene Unix-Systeme (etwa Linux) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.

Autoconf verwendet GNU m4, um aus einer vom Anwender erstellten Konfigurationsdatei configure.ac ein portierbares Shellskript namens configure zu erzeugen. Dieses configure-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die Systemumgebung angepasste Header- und Makefiles aus vorgefertigten Schablonen.

Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der Free Software Foundation zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare Open-Source-Software.

Autoconf verarbeitet Dateien (configure.in oder configure.ac, obwohl configure.ac generell bevorzugt wird^[2]), um ein Konfigurations script zu generieren.

Wird das generierte Konfigurationsscript ausgeführt, werden – soweit sie angegeben wurden – aus Vorlagen (die normalerweise die Endung „.in“ (z. B. Makefile.in) haben), die endgültigen Dateien generiert, in diesem Fall ein Makefile.

Autoconf wird dazu benutzt, kleinere Inkompatibilitäten auszubügeln, die in verschiedenen unixoiden Betriebssystemen gefunden wurden. Zum Beispiel haben einige unixoide Systeme Hilfsmittel, die als nicht funktionsfähig bekannt sind oder komplett fehlen. Autoconf erzeugt ein Shellskript, welches dies erkennen und umgehen kann. Der Output des Autoconf-Werkzeuges ist das Konfigurationsskript.

Autoconf enthält einige Hilfsprogramme, die entwickelt wurden, um das Erzeugen von configure.ac zu vereinfachen, darunter das Autoheader-Tool, das dazu benutzt wird, C-Header-Dateien zu handhaben, Autoscan, das eine anfängliche Datei für Autoconf erzeugt und ifnames, welche die C-Präprozessor identifier enthält, die im Programm benutzt werden.

Arbeitsweise

Autoconf arbeitet vergleichbar dem Metakonfigurationspaket von Perl.

Die Idee hinter autoconf ist die Prüfung auf die Verfügbarkeit von Eigenschaften, nicht von bestimmten Programmversionen. So unterstützt zum Beispiel der C-Compiler von SunOS 4 nicht den ISO-C-Standard. Eine reine versionsbasierte Vorgehensweise würde daher keinen ISO-C-Compiler auffinden, obwohl auf diesem System durchaus ein entsprechender Compiler vorhanden sein könnte. Erst der Ansatz, ein Zielsystem auf bestimmte Eigenschaften (Features) zu prüfen, führt hier zum gewünschten Ergebnis.

Üblicherweise wird durch die Datei configure.ac ein portables Skript namens „configure“ erzeugt. Vor dem Übersetzen des Quellcodes muss dieses Skript ausgeführt werden, um die systemabhängigen Makefiles und Headerdateien zu generieren und die Voraussetzungen an das System zu überprüfen. Wird das „configure“-Skript mit dem „--help“-Argument ausgeführt, werden die möglichen Optionen angezeigt.

GNU Autoheader

GNU Autoheader erzeugt eine Vorlage für eine Konfigurations-Header-Datei aus einer Autoconf-Konfigurationsdatei.^[3] Die Verwendung von GNU Autoheader ist optional. GNU Autoconf bzw. Automake ist auch ohne GNU Autoheader verwendbar. Wenn Autoheader nicht verwendet wird, dann müssen die von dem Projekt benötigten Konfigurationsmakros als Parameter bei jedem Compiler-Aufruf übergeben werden. Also können bei Nichtverwendung von autoheader, wenn das Projekt eine große Anzahl von Konfigurationsmakros benötigt, die Bildschirmausgaben von Compiler-Aufrufen unübersichtlich werden.

GNU Automake

Automake hilft bei der Erzeugung von portablen Makefiles, die der Reihe nach von make verarbeitet werden. Es erhält seine Eingaben als Makefile.am und wandelt es in eine Makefile.in-Datei um, die vom „configure“-Skript genutzt wird, um das letztendliche Makefile zu erzeugen.

GNU Libtool

Libtool hilft beim Erstellen von statischen und dynamischen Bibliotheken bei verschiedenen unixoiden Betriebssystemen. Libtool macht dies durch Abstrahieren des Erstellungsprozesses der Bibliothek, dabei versteckt es Unterschiede zwischen unterschiedlichen Systemen (beispielsweise von GNU/Linux-Systemen und Solaris).

Vorteile des GNU Build System

Das GNU Build System stellt einem Programmierer eine Umgebung bereit, mit der er Cross-platform-Software programmieren kann (die zumindest auf verschiedenen unixoiden Betriebssystemen ausgeführt werden kann). Es vereinfacht außerdem den Buildvorgang, weil der Nutzer normalerweise nur wenige Kommandos ausführen muss, um das Programm aus dem Quellcode zu erzeugen und zu installieren.

Die Werkzeuge, die vom GNU Build System benutzt werden, müssen dabei nur auf dem Computer des Entwicklers vorhanden sein. Die Nutzer selbst benötigen keine installierte Version von Autoconf, Automake oder Libtool, um die Software zu erstellen oder zu installieren, die mit deren Hilfe erzeugt wurde. Dies macht das GNU Build System unabhängig, weil es zum Erstellen nur Standardtools benötigt, die auf allen unixoiden Systemen vorhanden sind. Dies wird durch die Benutzung von Unix-Shellskripten bewerkstelligt, die dabei helfen, das Programm für das Betriebssystem des jeweiligen Nutzers zu konfigurieren.

Die Werkzeuge, die im GNU Build System genutzt werden, können sowohl einzeln als auch gemeinsam genutzt werden; zum Beispiel kann ein Softwareprojekt Autoconf nutzen, ohne auch Automake zu nutzen. Allerdings können die Komponenten des GNU Build System auch miteinander interagieren.

Verwertbare configure-Skripte entstehen auch auf sehr neuen oder vollkommen unbekannten Zielsystemen
Durch Parameter kann ein für das Zielsystem bestes Ergebnis (Größe, Geschwindigkeit, Stabilität) erreicht werden
Normalerweise werden keine exakten Softwareversionsvorgaben zur Übersetzung der Sourcen vorausgesetzt, sondern nur bestimmte Systemeigenschaften

Einschränkungen des GNU Build System

Das GNU Build System nutzt Bourne-kompatible Shellskripte, um dem Nutzer bei der Konfiguration und dem Buildvorgang zu helfen. Allerdings können einige Betriebssysteme, wie die Produktreihe Windows, Bourne-Shellskripte nicht alleine ausführen. Dies macht das Erstellen von Software beim Windows-Betriebssystem ein bisschen schwieriger als das Erstellen auf unixoiden, die standardmäßig Unterstützung für Bourne-Shellskripte implementiert haben.

Um Kompatibilität mit Konfigurationsscripts zu implementieren, kann man das Cygwin-System installieren. Cygwin liefert auch die GNU Compiler Collection, GNU Make und andere Software, die ein nahezu komplettes unixoides System in Windows erstellt. In zunehmendem Maße wird mit MinGW dadurch auch Cross-Compiling ermöglicht, um Software für einen Windows-Host von einem GNU/Linux oder anderen unixoiden Buildsystemen zu erstellen.

Projekte, die das GNU Build System nutzen, können wahlweise ein Konfigurationsscript in ihren Software-Configuration-Management Systemen (so wie CVS oder Subversion) bieten. Wenn ein Projekt, das das GNU Build System nutzt, kein generiertes ./configure-Skript für alle Nutzer bereitstellt, muss der Nutzer eines generieren. Ein möglicher Weg, dies zu bewerkstelligen, ist es, eine Reihe von Kommandos in einer Shell-Kommandozeile auszuführen:

$ aclocal
$ autoconf
$ autoheader
$ automake --add-missing

Es werden möglicherweise nicht alle oder mehrere Kommandos benötigt, abhängig davon in welcher Weise das vorhandene Projekt das GNU Build System nutzt. Darüber hinaus ist es auch üblich, ein Skript zur Verfügung zu stellen, oftmals benannt als autogen.sh, das alle genannten Pre-Build-Tools ausführt. In einigen Fällen kann man auch

$ autoreconf --install

benutzen, das automatisch die genannten Kommandos aufruft, falls sie benötigt werden.

Diskussion von Nachteilen und Kritik

Selbst wenn autoconf/automake/libtool/m4/…-basierte Build-Systeme die Portabilität erhöhen sollen, so funktioniert diese Vorgehensweise allzu oft nicht wie gewünscht; gerade Nicht-Linux-Builds und Cross-Builds erfordern viel zusätzliche Arbeit und Anpassungen.
Für Cross-Builds müssen die Konfigurationsscripte auf dem Zielsystem oder einem Cross-Compilation fähigen System ausgeführt werden; dies ist oft nicht, oder nur sehr umständlich möglich, wenn das Script und die zu seiner Erstellung erforderlichen Dateien nicht mitgeliefert werden und kann einen sehr hohen zusätzlichen Aufwand bedeuten.
Anpassungen sind, aufgrund der von vielen Entwicklern nicht sicher beherrschten M4-Makro-Sprache und der unübersichtlichen Struktur, aufwendig und fehlerträchtig.
Libtool-basierte Builds dauern wesentlich länger als einfache Make-Builds für ein bestimmtes System, da libtool per Default alle Libraries mehrfach baut (shared, static, teilweise sogar optimiert und debug-Version schon während des Entwicklungszyklus), so dass Development-Turnaround-Cycles mit den Default-Einstellungen deutlich länger dauern können als bei anderen Systemen. Auch der Overhead der Macro- und Shell-Aufrufe kann auf einigen Nicht-Linux-Systemen signifikant ausfallen.
In der Vergangenheit waren verschiedene Versionen von autoconf/automake/libtool/etc. nicht untereinander kompatibel; auf dem Entwicklungssystem mussten deshalb mehrere Versionen installiert und verwaltet werden, oder configure/Makefile-Input-Files erforderten ständige Anpassungen mit neuen Versionen.
Das KDE-Team verzichtet seit KDE4 auf autoconf/automake/libtool/etc. und verwendet an seiner Stelle CMake. Auch andere Projekte begannen mit der Evaluierung alternativer Buildsysteme. Ant und JAM sind weitere Ansätze. Integrierte Entwicklungsumgebungen (IDE) enthalten oft eigene Buildsysteme, die z. B. von CMake konfiguriert werden können.

Siehe auch

CMake
SCons

Literatur

Florian Stöhr: Die GNU Autotools : Leitfaden für die Softwaredistribution. C&L Computer & Literaturverlag, Böblingen 2007, ISBN 978-3-936546-48-4
John Calcote: Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool. 2. Auflage, No Starch Press, Daly City, California 2019, ISBN 978-1-59327-972-1

Weblinks

The Goat Book-Homepage (aka the Autobook)
Die GNU Coding Standards (besonders das Kapitel über The Release Process).
Das pkg-config-Package
GNU Automake-Homepage
GNU Autoconf-Homepage
„Hello World“ Example (PDF, 124 KiB)
Why the KDE project switched to CMake – and how
„Stop the autoconf insanity! Why we need a new build system.“ – kritischer Artikel über autoconf auf freshmeat.net

Einzelnachweise

↑ GNU Build System (automake). Abgerufen am 22. März 2018.
↑ Autoconf, “Writing configure.ac”
↑ http://www.seul.org/docs/autotut/#autoheader

[1] GNU Build System (automake). Abgerufen am 22. März 2018.

[GNU_Autoconf_Manual-2] Autoconf, “Writing configure.ac”

[3] ttps://www.seul.org/docs/autotut/#autoheader

[1]

[2]

[3]