Article on other languages:
 |
del.icio.us |
 |
Digg |
 |
Furl |
 |
|
 |
Rojo |
| Add to OnlyWire |
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-Packages in Unix-Systeme gedacht. Das GNU Build System ist Teil des 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.
Inhaltsverzeichnis |
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’s Makeprogramm, 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 benötigen zur Ausführung nicht mehr Autoconf.
Autoconf verwendet GNU m4, um eine vom Anwender erstellte Konfigurationsdatei configure.ac in 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 Templates.
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.
Wenn das generierte Konfigurationsscript ausgeführt wird, werden andere Vorlagen, die normalerweise die Endung „.in“ haben, so wie Makefile.in, verarbeitet, um das endgültige Output zu generieren, 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, die dieses erkennen und umgehen kann. Der Output des Autoconf-Werkzeug ist das Konfigurationsskript.
Autoconf enthält einige Hilfsprogramme, die entwickelt wurden, um das Erzeugen der configure.ac zu vereinfachen, darunter das Autoheader-Tool, das dazu benutzt wird, C Headerdateien zu handhaben, 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 Features, 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 nicht-Verwendung 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 von Autoconf 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 können). Es vereinfacht außerdem den Buildvorgang, weil der Nutzer normalerweise nur ein paar Kommandos ausführen muss, um das Programm aus dem Quellcode zu erzeugen und zu installieren.
Die Werkzeuge, die vom GNU Build System benutzt werden, brauchen nur auf dem Computer des Entwicklers vorhanden zu 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 agieren.
- 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.
Quellenangaben
Siehe auch
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
- Why the KDE project switched to CMake – and how
- Onlineversion des Buches "GNU autoconf, automake, libtool"
