GNU Build System

Programmablaufplan von autoconf und automake, zwei Tools im GNU Build System

Das GNU Build System, auch bekannt als Autotools, ist eine Sammlung von Tools für die Computerprogrammierung, 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 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^[1]) um ein Konfigurationsscript 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 Shell-Skript, 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-Headerdateien handzuhaben, Autoscan, das eine anfängliche Datei für Autoconf erzeugt und ifnames, welche die C-Präprozessoridentifier 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^[2]. 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 kann 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 Systeme 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 Shell-Scripts 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 Systems 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 Systems

Das GNU Build System nutzt Bourne-kompatible Shellscripts, um dem Nutzer bei der Konfiguration und dem Buildvorgang zu helfen. Allerdings können einige Betriebssysteme, wie die Produktreihe Microsoft Windows, Bourne-Shellscripte nicht alleine ausführen. Dies macht das Erstellen von Software beim Windows Betriebssystem ein bisschen schwerer als das Erstellen auf unixoiden, die standardmäßig Unterstützung für Bourne-Shellscripte 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 einen Windows-Host von einem GNU/Linux oder anderen unixoiden Buildsystemen auszuführen. Seit den Anfängen von MSYS wird die Benutzung von Cygwin weniger notwendig, wenn man das MinGW-Toolkit benutzt, weil es zur Integration der Autotools eine Umgebung schafft, die größtenteils-POSIX kompatibel ist.

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

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

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 config-Files auf dem Target generiert werden; dies ist oft nicht oder nur sehr umständlich möglich und kann einen sehr hohen 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 definiertes Target, 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-Settings deutlich länger dauern können als bei anderen Systemen. Auch der Overhead der Macro- und Shell-Aufrufe bedeutet auf einigen Nicht-Linux-Systemen einen signifikanten Overhead.
• In der Vergangenheit waren verschiedene autoconf/automake/libtool/etc-Versionen 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 Evaluation anderer Buildsysteme. ANT und JAM sind alternative Ansätze, integrierte Entwicklungsumgebungen (IDE) enthalten oft eigene Buildsysteme, die z. B. von CMake konfiguriert werden können.

Einzelnachweise

1. ↑ Autoconf, “Writing configure.ac”
2. ↑ http://www.seul.org/docs/autotut/#autoheader

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

Weblinks

• Automake und Autoconf mit C++ nutzen
• The Goat Book-Homepage (aka the Autobook)
• Die GNU Coding Standards (besonders das Kapitel über The Release Process).
• Das pkg-config-Package
• Ein Autotools Tutorial für Anfänger.
• Automake-Handbuch
• GNU Automake-Homepage
• GNU Autoconf-Homepage
• Autotools-Tutorial für Anfänger
• Autotools-Tutorial
• „Hello World“ Example (PDF-Datei; 124 kB)
• Why the KDE project switched to CMake – and how
• Onlineversion des Buches „GNU autoconf, automake, libtool“
• „Stop the autoconf insanity! Why we need a new build system.“ Kritischer Artikel über autoconf auf freshmeat.net

Siehe auch

• CMake
• SCons