GNU Autotools - GNU Autotools
Die GNU Autotools , auch als GNU Build System bekannt , sind eine Reihe von Programmiertools , mit denen Quellcode- Pakete auf viele Unix-ähnliche Systeme portierbar gemacht werden können.
Es kann schwierig sein, ein Softwareprogramm portabel zu machen: Der C-Compiler unterscheidet sich von System zu System; Auf einigen Systemen fehlen bestimmte Bibliotheksfunktionen. Header-Dateien können unterschiedliche Namen haben. Eine Möglichkeit, dies zu handhaben, besteht darin, bedingten Code zu schreiben, wobei Codeblöcke mithilfe von Präprozessoranweisungen ( #ifdef
) ausgewählt werden. Aufgrund der Vielzahl von Build-Umgebungen ist dieser Ansatz jedoch schnell nicht mehr zu handhaben. Autotools wurde entwickelt, um dieses Problem besser zu lösen.
Autotools ist Teil der GNU-Toolchain und wird häufig in vielen freien Software- und Open Source- Paketen verwendet. Die Komponententools sind freie Software , die unter der GNU General Public License lizenziert ist, mit speziellen Lizenzausnahmen, die die Verwendung mit proprietärer Software ermöglichen .
Das GNU Build System ermöglicht es, viele Programme in einem zweistufigen Prozess zu erstellen: configure gefolgt von make .
Komponenten
Autotools besteht aus den GNU- Dienstprogrammen Autoconf , Automake und Libtool . Weitere verwandte Tools, die häufig verwendet werden, sind das make- Programm von GNU, GNU gettext , pkg-config und die GNU Compiler Collection , auch GCC genannt.
GNU Autoconf
Autoconf generiert ein configure
Skript basierend auf dem Inhalt einer configure.ac
Datei, das einen bestimmten Quellcode kennzeichnet. Das configure
Skript, wenn Lauf tastet die Umgebung build und erzeugt eine untergeordnete config.status
Skript, das wiederum wandelt andere Eingabedateien und am häufigsten Makefile.in
in den Ausgabedateien ( Makefile
), die für die Erstellungsumgebung geeignet sind. Schließlich generiert das make
Programm Makefile
ausführbare Programme aus dem Quellcode.
Die Komplexität von Autotools spiegelt die verschiedenen Umstände wider, unter denen ein Quellcode erstellt werden kann.
- Wenn eine Quellcodedatei geändert wird, reicht es aus, sie erneut auszuführen
make
, wodurch nur der Teil des Körpers des Quellcodes neu kompiliert wird, der von der Änderung betroffen ist. - Wenn eine
.in
Datei geändert hat , dann genügt es , zu re-runconfig.status
undmake
. - Wenn der Quellcode auf einen anderen Computer kopiert wird, reicht es aus, ihn erneut auszuführen
configure
(der ausgeführt wirdconfig.status
) undmake
. (Aus diesem Grund wird Quellcode, der Autotools verwendet, normalerweise ohne dieconfigure
generierten Dateien verteilt .) - Wenn der Hauptteil des Quellcodes grundlegender geändert wird, müssen
configure.ac
die.in
Dateien geändert werden, und alle nachfolgenden Schritte müssen ebenfalls ausgeführt werden.
Zur Verarbeitung von Dateien verwendet autoconf die GNU-Implementierung des m4- Makrosystems.
Autoconf wird mit mehreren Hilfsprogrammen geliefert, z. B. autoheader
zur Verwaltung von C- Header-Dateien . autoscan
, die eine erste Eingabedatei für Autoconf erstellen kann; und ifnames
, die C Präprozessor-IDs auflisten können, die im Programm verwendet werden.
GNU Automake
Automake hilft beim Erstellen von tragbaren Makefile
Geräten, die wiederum mit dem Dienstprogramm make verarbeitet werden . Es nimmt seine Eingabe als Makefile.am
und wandelt sie in eine um Makefile.in
, die vom Konfigurationsskript zum Generieren der Dateiausgabe verwendet Makefile
wird. Es führt auch eine automatische Abhängigkeitsverfolgung durch. Jedes Mal, wenn eine Quelldatei kompiliert wird, wird die Liste der Abhängigkeiten (z. B. C-Header-Dateien) aufgezeichnet. Später, wenn make ausgeführt wird und sich eine Abhängigkeit geändert zu haben scheint, werden die abhängigen Dateien neu erstellt.
GNU Libtool
Libtool hilft bei der Verwaltung der Erstellung statischer und dynamischer Bibliotheken auf verschiedenen Unix-ähnlichen Betriebssystemen. Libtool erreicht dies, indem es den Prozess der Bibliothekserstellung abstrahiert und Unterschiede zwischen verschiedenen Systemen (z. B. Linux- Systeme vs. Solaris ) verbirgt .
Verwendung
Autotools unterstützt Softwareentwickler dabei, plattformübergreifende Software zu schreiben und sie einer viel breiteren Benutzergemeinschaft zur Verfügung zu stellen, auch in ihrer Quellcodeform für diejenigen Benutzer, die die Software selbst erstellen möchten. In den meisten Fällen führen Benutzer einfach das bereitgestellte configure
Skript (das keine anderen Abhängigkeiten als das Vorhandensein einer Bourne-kompatiblen Shell aufweist ) und anschließend ein make
Programm aus. Sie müssen die Autotools nicht selbst auf dem Computer installiert haben.
Es kann sowohl zum Erstellen nativer Programme auf der Build-Maschine als auch zum Cross-Compilieren mit anderen Architekturen verwendet werden.
Cross-Compiling-Software für die Ausführung auf einem Windows-Host von einem Linux- oder einem anderen Unix-ähnlichen Build-System ist mit MinGW ebenfalls möglich. Eine native Kompilierung ist jedoch häufig auf Betriebssystemen (wie der Microsoft Windows- Systemfamilie) wünschenswert, auf denen Bourne nicht ausgeführt werden kann Shell-Skripte für sich. Dies macht das Erstellen einer solchen Software unter dem Windows-Betriebssystem etwas schwieriger als auf einem Unix-ähnlichen System, das die Bourne-Shell als Standardkomponente bereitstellt. Sie können das Cygwin- oder MSYS- System jedoch über Windows installieren , um eine Unix-ähnliche Kompatibilitätsschicht bereitzustellen , mit der Konfigurationsskripts ausgeführt werden können. Cygwin bietet auch die GNU Compiler Collection , GNU make und andere Software, die ein nahezu vollständiges Unix-ähnliches System unter Windows bietet. MSYS bietet auch GNU make und andere Tools, die für die MinGW- Version von GCC entwickelt wurden.
Obwohl vom Entwickler erwartet wird, dass er ein Konfigurationsskript für den Endbenutzer bereitstellt , möchte der Benutzer gelegentlich das Konfigurationsskript selbst neu generieren. Eine solche Arbeit kann erforderlich sein, wenn der Benutzer den Quellcode selbst ändern möchte. Solche Benutzer müssten Autotools installiert haben und Komponenten wie die Autoreconf verwenden .
Die automatisch erzeugte Konfiguration configure
kann langsam sein, da sie Programme wie einen C-Compiler viele Male ausführt, um zu testen, ob verschiedene Bibliotheken, Header-Dateien und Sprachfunktionen vorhanden sind. Dies betrifft insbesondere Cygwin , das aufgrund des Fehlens eines nativen Fork-Systemaufrufs Konfigurationsskripte möglicherweise erheblich langsamer als Linux ausführt .
Kritik
In seiner Kolumne für ACM Queue , FreeBSD - Entwickler Poul-Henning Kamp kritisierte das GNU Build - System:
Die Idee ist, dass das Konfigurationsskript ungefähr 200 automatisierte Tests durchführt, damit der Benutzer nicht mit der manuellen Konfiguration von libtool belastet wird. Dies ist eine schrecklich schlechte Idee, die bereits in den 1980er Jahren vielfach kritisiert wurde, als sie erschien, da der Quellcode vorgibt, hinter dem Furnier des Konfigurationsskripts portierbar zu sein, anstatt zunächst die Qualität der Portabilität zu haben. Es ist eine Farce, dass die Konfigurationsidee überlebt hat.
Kamp skizziert die Geschichte des Build-Systems in Bezug auf die Portabilitätsprobleme, die mit der Vielzahl der Unix-Varianten der 1980er Jahre verbunden sind , und beklagt die Notwendigkeit, dass solche Build-Systeme existieren:
Die 31.085 Konfigurationszeilen für libtool prüfen weiterhin, ob <sys / stat.h> und <stdlib.h> vorhanden sind, obwohl das Unixen, dem sie fehlten, weder über ausreichend Speicher zum Ausführen von libtool noch über Festplatten verfügte, die groß genug für 16 MB waren Quellcode.
Reaktionen auf Kritik
Obwohl Kritiker der Autotools häufig für Alternativen eintreten, die ihren Benutzern eine größere Einfachheit bieten, haben einige argumentiert, dass dies nicht unbedingt eine gute Sache ist. John Calcote, Autor der Autotools, 2. Auflage: Ein Leitfaden für Praktiker zu GNU Autoconf, Automake und Libtool , meinte:
Die Autotools sind tatsächlich transparenter als alle anderen Build-Tools. Alle diese anderen Tools (cmake, maven usw.) - die angeblich so viel einfacher sind, weil sie den Benutzer von den zugrunde liegenden Details des Erstellungsprozesses isolieren - bestehen hauptsächlich darin, dass diese Isolierung den Benutzer davon abhält, sie zu erstellen die Änderungen, die sie benötigen, um ihre einzigartigen projektspezifischen Build-Ziele zu erreichen.
Jeder, der nur Gutes über diesen Aspekt von cmake, maven, gradle oder was auch immer zu sagen hat, hat einfach nicht an einem Projekt gearbeitet, bei dem er sich weit genug von den Standardeinstellungen entfernen muss. Ich habe sie alle verwendet und stundenlang frustriert versucht, herauszufinden, wie die Mängel einiger "Alleskönner" -Funktionen (außer dem, was ich will) behoben werden können. Dies ist bei den Autotools einfach kein Problem. Wie bereits in diesem Thread erwähnt, können Sie das Shell-Skript in eine configure.ac-Datei einfügen und das Skript in eine Makefile.am-Datei umwandeln. Das ist genau die Definition von Transparenz. Kein anderes vorhandenes Tool ermöglicht dieses Maß an Flexibilität.
Siehe auch
- Liste der Build-Automatisierungssoftware § Tools zur Erstellung von Skripten
- Automatisierung erstellen
- CMake
- Gnits Standards
- GNU-Codierungsstandards
- Waf
- SCons
- Meson Build System
- Qmake
Verweise
Externe Links
- Das GNU-Konfigurations- und Build-System
- Das Paket pkg-config
- GNU automake Dokumentation
- GNU Autoconf Dokumentation
- Kombiniertes Handbuch für Automake und Autoconf
- Autotools Tutorial
- GNU Autoconf, Automake und Libtool
- Autotools: Ein Leitfaden für Praktiker zu Autoconf, Automake und Libtool
- Ein Leitfaden zur Integration von CUDA in Autotools
- Autotools Mythbuster
- Einführung in die Autotools