Ist automake und autoconf die Standardmethode zum Kompilieren von Code?


22

Ich kompiliere manchmal Apps aus dem Quellcode und verwende entweder:

./configure
make
sudo make install

Aber vor kurzem bin ich auf ./autogen.shdas gestoßen, das das Konfigurieren und Erstellen von Skripten für mich generiert und diese ausführt.

Welche anderen Methoden zur Optimierung der C / C ++ / C # -Kompilierung (Mono) gibt es? Make scheint ein bisschen alt zu sein. Gibt es da draußen neue Tools? Welche soll ich bei der Auswahl verwenden?


Es gibt nichts Besseres als 'Code'. Wenn Sie beispielsweise Java-Code erhalten, werden Sie ihn wahrscheinlich mit maven oder ant erstellen. Wenn Sie Python erhalten, ist setuptools eine gute Wahl. Es gibt keine Standardmethoden, um etwas zu kompilieren. Vielleicht sollten Sie die Frage umformulieren.
Diega

Guter Punkt. Ich programmiere eigentlich in C # mit Mono, aber meine Frage gilt auch für C / C ++.
Louis Salin

Kleiner Hinweis: autogen.sh führt make nicht für Sie aus, sondern konfiguriert es einfach.
Sandy

@Sandy autogen.shsind meist benutzerdefinierte Skripts, die in der Regel invoke autoreconfaber auch berufen könnte ./configureund sogar make. Ich glaube nicht, dass sein Verhalten in irgendeiner Weise standardisiert ist. Der Hauptzweck ist es, eine ausführbare Datei innerhalb des Projekts zu haben, die die Leute ausführen können (anstatt zu wissen, dass sie sie heraufbeschwören müssen autoreconf)
umläute

Antworten:


42

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 && makeSie 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 distund make distcheckwü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


Nur eine Nebensache: Die GNU-Standards schreiben vor, generierte Dateien in Tarballs zu versenden, um die Build-Abhängigkeiten auf ein Minimum an universell verfügbaren Tools zu reduzieren. Wenn Sie eine unformatierte Quelle (z. B. von einem Versionskontrollsystem) erhalten, sind die generierten Dateien nicht vorhanden.
Vonbrand

14

In diesem Bereich gibt es zwei "Big Player". Cmake und GNU Autotools.

  • GNU Autotools ist die GNU-Methode, um Dinge zu tun, und konzentriert sich ziemlich auf * nix. 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. Auf diese Weise können Sie mehr Änderungen an Ihrem Code vornehmen, ohne Ihr Build-System direkt manipulieren zu müssen, und andere können Ihren Code auf eine Weise erstellen, für die Sie nicht entworfen haben - unter * nix.

  • Cmake ist die plattformübergreifende Möglichkeit, Dinge zu tun. Das Cmake-Team erstellt Software auf viele verschiedene Arten, mit GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux, was auch immer. Wenn Sie überhaupt mit der Portabilität Ihrer Codebasis befasst sind, ist dies der richtige Weg.

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

Ruby hat auch eine Art Meta-Build-System namens Rake, das an sich ziemlich cool ist und sehr praktisch für diejenigen ist, die bereits mit Ruby vertraut sind.


6

Scons ist ein möglicher Ersatz, obwohl ich keine persönliche Erfahrung habe. Es ist auch in Python implementiert, was je nach Build-Umgebung ein Problem sein kann.


2
Portabilität ist nicht das Problem, da Python jetzt praktisch überall ist. Die Hauptbeschwerde über SCons ist bisher, dass es unannehmbar langsam ist. Es gibt einige Verbesserungen, um die Build-Genauigkeit zugunsten der Geschwindigkeit zu opfern, aber ich bin mir nicht sicher, ob es immer noch mit Make vergleichbar ist.
Alex B

3

Wenn Sie C # / Mono verwenden, können Sie msbuild (die von MonoDevelop und Visual Studio verwendeten .sln / .csproj-Dateien) verwenden, um Ihren gesamten Erstellungsprozess zu verwalten.

Sie können dann entweder aus MonoDevelop erstellen oder den xbuildBefehl in Ihrem bevorzugten Terminal ausführen (funktioniert am besten in Mono> = 2.6). Dies ist extrem einfach und erfordert so gut wie keine Arbeit von Ihrer Seite, da MonoDevelop die msbuild-Dateien für Sie handhabt und Sie sie nicht bearbeiten müssen, es sei denn, Sie möchten Dinge optimieren, die über die Benutzeroberfläche von MonoDevelop hinausgehen.

Ich bin nicht vertraut damit, wie Leute, die von msbuild abhängig sind, die Installationen für ihre Projekte handhaben, aber das könnte man immer fragen. ;-)


Ja, ich weiß über xbuild Bescheid, aber ich versuche mich von IDEs zu entwöhnen, die nur meine Hand halten wollen. Außerdem wird Mono mit Mono kompiliert und verwendet Autoconf. Deshalb wollte ich etwas mehr wissen. Vielen Dank!
Louis Salin

1
Interessanterweise versuchen viele Mono-Projekte nach msbuild zu migrieren, da xbuild so gut funktioniert. Dadurch wird die Windows / Mac-Unterstützung etwas einfacher. Mono hat so viel C-Code, dass ich mir nicht sicher bin, wie praktisch es für sie wäre, auf xbuild umzusteigen. Aber autoconf funktioniert großartig. Tun Sie also, was auch immer für Sie funktioniert. :-)
Sandy

0

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

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.