☰

Sind Automake und Autoconf die Standardmethode zum Kompilieren von Code?

tag-icon • tag-icon compiling programming
Sind Automake und Autoconf die Standardmethode zum Kompilieren von Code?

Ich kompiliere manchmal Apps aus dem Quellcode und habe entweder Folgendes verwendet:

./configure
make
sudo make install

Aber vor kurzem bin ich auf ein Programm gestoßen ./autogen.sh, das die Konfigurations- und Erstellungsskripte für mich generiert und ausführt.

Welche anderen Methoden gibt es, um die C/C++/C#(Mono)-Kompilierung zu optimieren? Make scheint etwas veraltet zu sein. Gibt es neue Tools? Wenn ich die Wahl hätte, welches sollte ich verwenden?

Antwort1

Autoconf und Automake wurden entwickelt, um ein evolutionäres Problem von Unix zu lösen.

Als sich Unix in verschiedene Richtungen entwickelte, neigten Entwickler, die portablen Code wollten, dazu, Code wie diesen 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

Als Unix in verschiedene Implementierungen aufgespalten wurde (BSD, SystemV, viele Anbieter-Forks und später Linux und andere Unix-ähnliche Systeme), wurde es für Entwickler, die portablen Code schreiben wollten, wichtig, Code zu schreiben, der nicht von einer bestimmten Marke des Betriebssystems abhängig war, sondern von den vom Betriebssystem bereitgestellten Funktionen. Dies ist wichtig, weil eine Unix-Version eine neue Funktion einführte, beispielsweise den Systemaufruf „send“, und später andere Betriebssysteme diese übernahmen. Anstatt einen Code-Spaghetti zu haben, der nach Marken und Versionen suchte, begannen Entwickler, nach Funktionen zu suchen, sodass der Code zu Folgendem wurde:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

In den meisten README-Dateien zum Kompilieren von Quellcode aus den 90er Jahren wurden Entwickler angewiesen, eine config.h-Datei zu bearbeiten und die entsprechenden auf dem System verfügbaren Funktionen auszukommentieren, oder es wurden standardmäßige config.h-Dateien für jede getestete Betriebssystemkonfiguration mitgeliefert.

Dieser Prozess war sowohl mühsam als auch fehleranfällig und so entstand Autoconf. Sie sollten sich Autoconf als eine Sprache vorstellen, die aus Shell-Befehlen mit speziellen Makros besteht und den menschlichen Bearbeitungsprozess der config.h durch ein Tool ersetzen konnte, das das Betriebssystem auf Funktionalität prüfte.

Normalerweise schreiben Sie Ihren Prüfcode in die Datei configure.ac und führen dann den Befehl autoconf aus, der diese Datei in den ausführbaren Konfigurationsbefehl kompiliert, den Sie verwendet gesehen haben.

Beim Ausführen ./configure && makehaben Sie also nach den auf Ihrem System verfügbaren Funktionen gesucht und dann die ausführbare Datei mit der erkannten Konfiguration erstellt.

Als Open-Source-Projekte begannen, Quellcode-Kontrollsysteme zu verwenden, war es sinnvoll, die Datei configure.ac einzuchecken, nicht jedoch das Ergebnis der Kompilierung (configure). Die Datei 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 der Community entstanden. Das GNU-Projekt standardisierte einen regelmäßigen Satz von Zielen für Makefiles:

  • make allwürde das Projekt bauen
  • make cleanwürde alle kompilierten Dateien aus dem Projekt entfernen
  • make installwürde die Software installieren
  • Dinge wie make distund make distcheckwürde die Quelle für die Verteilung vorbereiten und überprüfen, ob das Ergebnis ein vollständiges Quellcodepaket war
  • und so weiter...

Das Erstellen konformer Makefiles wurde mühsam, da es viele Boilerplate-Codes gab, die immer wieder wiederholt wurden. Deshalb wurde Automake zu einem neuen Compiler, der in Autoconf integriert wurde und „Quell“-Makefiles (mit dem Namen Makefile.am) in Makefiles verarbeitete, die dann in Autoconf eingespeist werden konnten.

Die Automake/Autoconf-Toolchain verwendet tatsächlich eine Reihe anderer Hilfstools und diese werden durch andere Komponenten für andere spezifische Aufgaben ergänzt. Als die Komplexität der Ausführung dieser Befehle in der richtigen Reihenfolge zunahm, entstand der Bedarf nach einem lauffähigen Skript, und hieraus entstand autogen.sh.

Soweit ich weiß, war Gnome ein Projekt, das die Verwendung dieses Hilfsskripts autogen.sh einführte

Antwort2

Auf diesem Gebiet gibt es zwei „große Player“: Cmake und GNU Autotools.

  • GNU Autotools ist die GNU-Methode, die Dinge zu erledigen, und ist ziemlich auf *nix ausgerichtet. Es ist eine Art Meta-Build-System, das eine Reihe von Tools bereitstellt, die spezifische Konfigurationen generieren und Dateien für das erstellen, was Sie tun möchten. Dies hilft Ihnen, mehr Änderungen an Ihrem Code vorzunehmen, ohne Ihr Build-System direkt manipulieren zu müssen, und es hilft anderen, Ihren Code auf eine Weise zu erstellen, für die Sie ihn nicht entwickelt haben – unter *nix.

  • Cmake ist die plattformübergreifende Methode, Dinge zu erledigen. Das Cmake-Team erstellt Software auf viele, viele, viele verschiedene Arten, mit GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU/Linux, was auch immer. Wenn Sie sich auch nur im Geringsten um die Portabilität Ihrer Codebasis sorgen, ist dies der richtige Weg.

Wie bereits erwähnt, scheinen einige Leute Scons zu mögen. Wenn Sie mit Python vertraut sind, kann dies für mehr Konsistenz in Ihrer Arbeitsumgebung sorgen.

Ruby verfügt außerdem über eine Art Meta-Build-System namens Rake, das an sich ziemlich cool ist und für diejenigen, die bereits mit Ruby vertraut sind, sehr praktisch ist.

Antwort3

Sconsist ein möglicher Ersatz, obwohl ich keine persönlichen Erfahrungen habe. Es ist auch in Python implementiert, was je nach Build-Umgebung ein Problem darstellen könnte.

Antwort4

Für C# können Sie xbuild (und msbuild unter Windows) verwenden, das das Projekt aus Ihren Projektdateien erstellt.

verwandte Informationen