Autoconf und Automake sollten ein evolutionäres Problem von Unix lösen.
Als sich Unix in verschiedene Richtungen entwickelte, neigten Entwickler, die portablen Code wollten, dazu, Code wie folgt zu schreiben:
#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif
Da Unix in verschiedene Implementierungen (BSD, SystemV, viele Herstellerforks und später Linux und andere Unix-ähnliche Systeme) eingebunden war, wurde es für Entwickler wichtig, portablen Code zu schreiben, um Code zu schreiben, der nicht von einer bestimmten Marke des Betriebssystems abhängt , aber auf Funktionen des Betriebssystems ausgesetzt. Dies ist wichtig, da eine Unix-Version eine neue Funktion einführen würde, zum Beispiel den Systemaufruf "send", und später andere Betriebssysteme dies übernehmen würden. Anstatt eine Spaghetti aus Code zu haben, die nach Marken und Versionen suchte, begannen die Entwickler, nach Funktionen zu suchen, sodass aus Code Folgendes wurde:
#if HAVE_SEND
Use Send here
#else
Use something else
#endif
Die meisten README-Dateien zum Kompilieren von Quellcode in den 90er Jahren wiesen die Entwickler darauf hin, eine config.h-Datei zu bearbeiten und die auf dem System verfügbaren Funktionen zu kommentieren, oder es wurden Standard-config.h-Dateien für jede getestete Betriebssystemkonfiguration ausgeliefert.
Dieser Prozess war sowohl umständlich als auch fehleranfällig, und so entstand Autoconf. Sie sollten sich Autoconf als eine Sprache vorstellen, die aus Shell-Befehlen mit speziellen Makros besteht, die den menschlichen Bearbeitungsprozess der config.h durch ein Tool ersetzen konnten, das das Betriebssystem auf Funktionalität überprüft hat.
Normalerweise schreiben Sie Ihren Prüfcode in die Datei configure.ac und führen dann den Befehl autoconf aus, der diese Datei zu dem ausführbaren Befehl configure kompiliert, den Sie verwendet haben.
Während der Ausführung haben ./configure && make
Sie nach den auf Ihrem System verfügbaren Funktionen gesucht und anschließend die ausführbare Datei mit der erkannten Konfiguration erstellt.
Als Open Source-Projekte mit Quellcode-Kontrollsystemen begannen, war es sinnvoll, die Datei configure.ac einzuchecken, nicht jedoch das Ergebnis der Kompilierung (configure). Die autogen.sh ist lediglich ein kleines Skript, das den autoconf-Compiler mit den richtigen Befehlsargumenten für Sie aufruft.
-
Automake ist auch aus bestehenden Praktiken in der Community gewachsen. Das GNU-Projekt standardisierte eine regelmäßige Reihe von Zielen für Makefiles:
make all
würde das Projekt bauen
make clean
würde alle kompilierten Dateien aus dem Projekt entfernen
make install
würde die Software installieren
- Dinge wie
make dist
und make distcheck
würden die Quelle für die Verteilung vorbereiten und sicherstellen, dass das Ergebnis ein vollständiges Quellcode-Paket ist
- und so weiter...
Das Erstellen von kompatiblen Makefiles wurde mühsam, da es viele Boilerplates gab, die immer wieder wiederholt wurden. Automake war also ein neuer Compiler, der sich in autoconf integrierte und "Quell" -Makefiles (Makefile.am) in Makefiles verarbeitete, die dann an Autoconf weitergeleitet werden konnten.
Die Toolchain automake / autoconf verwendet tatsächlich eine Reihe anderer Hilfsprogramme, die durch andere Komponenten für andere spezifische Aufgaben erweitert werden. Als die Komplexität der Ausführung dieser Befehle in der richtigen Reihenfolge zunahm, wurde der Bedarf an einem sofort ausführbaren Skript geboren, von dem autogen.sh abstammt.
Soweit mir bekannt ist, war Gnome ein Projekt, das die Verwendung dieses Hilfsskripts autogen.sh eingeführt hat