2001:9E8:6C63:2E01:3D9A:AD77:A542:EF8B: /* Diskussion von Nachteilen und Kritik */ Zeichensetzung und so

2025-04-17T12:57:16Z

Diskussion von Nachteilen und Kritik: Zeichensetzung und so

Neue Seite

[[Datei:Autoconf-automake-process.svg|mini|400px|Programmablaufplan von [[autoconf]] und [[automake]], zwei Tools im ''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 [[Plattformunabhängigkeit|Portieren]] von [[Quellcode]]-[[Programmpaket|Paketen]] auf [[Unix]]-Systemen gedacht. Das ''GNU Build System'' ist Teil der [[GNU Toolchain]]s und ist in [[Freie Software|freien]] Software-Projekten weit verbreitet. Während die Werkzeuge selbst [[freie Software]] sind und unter der [[GNU General Public License|GPL]] stehen, können auch [[Proprietäre Software|proprietäre Projekte]] damit entwickelt werden.

== Enthaltene Werkzeuge ==
Das ''GNU Build System'' wird durch die sogenannten '''Autotools''' erstellt<ref>{{Internetquelle |url=https://www.gnu.org/software/automake/manual/html_node/GNU-Build-System.html#GNU-Build-System |titel=GNU Build System (automake) |zugriff=2018-03-22}}</ref>. 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-[[Skriptsprache|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler|Übersetzen]] des [[Quellcode]]s 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 (Programmiersprache)|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit|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|Open-Source-Software]].

Autoconf verarbeitet Dateien (<code>configure.in</code> oder <code>configure.ac</code>, obwohl <code>configure.ac</code> generell bevorzugt wird<ref name="GNU Autoconf Manual">[http://www.gnu.org/software/autoconf/manual/html_node/Writing-Autoconf-Input.html ''Autoconf'', “Writing configure.ac”]</ref>), um ein [[Konfiguration (Computer)|Konfigurations]][[Skriptdatei|script]] zu generieren.

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

Autoconf wird dazu benutzt, kleinere Inkompatibilitäten auszubügeln, die in verschiedenen [[unixoid]]en 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 (Programmiersprache)|C]]-[[Header-Datei]]en 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 (Programmiersprache)|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 (Programmiersprache)|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.<ref>http://www.seul.org/docs/autotut/#autoheader</ref> 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 <code>Makefiles</code>, die der Reihe nach von <span style="font-family:monospace;">[[make]]</span> verarbeitet werden. Es erhält seine Eingaben als <code>Makefile.am</code> und wandelt es in eine <code>Makefile.in</code>-Datei um, die vom „configure“-Skript genutzt wird, um das letztendliche <code>Makefile</code> zu erzeugen.

=== GNU Libtool ===
''Libtool'' hilft beim Erstellen von [[Statische Bibliothek|statischen]] und [[Dynamische Bibliothek|dynamischen]] [[Programmbibliothek|Bibliotheken]] bei verschiedenen [[unixoid]]en Betriebssystemen. Libtool macht dies durch Abstrahieren des Erstellungsprozesses der Bibliothek, dabei versteckt es Unterschiede zwischen unterschiedlichen Systemen (beispielsweise von [[GNU]]/[[Linux]]-Systemen und [[Solaris (Betriebssystem)|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 [[unixoid]]en [[Betriebssystem]]en ausgeführt werden kann). Es vereinfacht außerdem den [[Erstellungsprozess|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 [[unixoid]]en Systemen vorhanden sind. Dies wird durch die Benutzung von [[Unix-Shell|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-Shell|Bourne-kompatible Shellskripte]], um dem Nutzer bei der Konfiguration und dem Buildvorgang zu helfen. Allerdings können einige Betriebssysteme, wie die Produktreihe [[Microsoft Windows|Windows]], Bourne-Shellskripte nicht alleine ausführen. Dies macht das Erstellen von Software beim Windows-Betriebssystem ein bisschen schwieriger als das Erstellen auf [[unixoid]]en, 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 [[Concurrent Versions System|CVS]] oder [[Apache Subversion|Subversion]]) bieten. Wenn ein Projekt, das das ''GNU Build System'' nutzt, kein generiertes <code>./configure</code>-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 <code>autogen.sh</code>, 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), sodass 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. [[Apache Ant|Ant]] und [[Perforce Jam|JAM]] sind weitere Ansätze. [[Integrierte Entwicklungsumgebung]]en (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 ==
* [http://sources.redhat.com/autobook/ ''The Goat Book''-Homepage (aka the Autobook)]
* Die [http://www.gnu.org/prep/standards.html GNU Coding Standards] (besonders das Kapitel über ''The Release Process'').
* Das [http://www.freedesktop.org/software/pkgconfig/ pkg-config]-Package
* [http://www.gnu.org/software/automake/ GNU Automake-Homepage]
* [http://www.gnu.org/software/autoconf/ GNU Autoconf-Homepage]
* [https://www-user.tu-chemnitz.de/~dker/autotools_tutorial.pdf „Hello World“ Example] (PDF, 124 KiB)
* [http://lwn.net/Articles/188693/ Why the KDE project switched to CMake – and how]
* [http://freshmeat.net/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system „Stop the autoconf insanity! Why we need a new build system.“] – kritischer Artikel über autoconf auf freshmeat.net

== Einzelnachweise ==
<references />

{{SORTIERUNG:Gnu build system}}
[[Kategorie:Softwaretechnik]]
[[Kategorie:Freies Programmierwerkzeug]]
[[Kategorie:GNU-Paket]]

GNU Build System - Versionsgeschichte

2001:9E8:6C63:2E01:3D9A:AD77:A542:EF8B: /* Diskussion von Nachteilen und Kritik */ Zeichensetzung und so