GNU Autotools - GNU Autotools

GNU-Logo

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

Flussdiagramm von Autoconf und Automake

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-run config.status und make .
  • Wenn der Quellcode auf einen anderen Computer kopiert wird, reicht es aus, ihn erneut auszuführen configure (der ausgeführt wird config.status ) und make . (Aus diesem Grund wird Quellcode, der Autotools verwendet, normalerweise ohne die configure 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

Verweise

Externe Links