Warum immer ./configure; machen; make install; als 3 separate Schritte?

Jedes Mal, wenn Sie etwas aus dem Quellcode kompilieren, gehen Sie die gleichen drei Schritte durch:

$ ./configure
$ make
$ make install

Ich verstehe, dass es sinnvoll ist, den Installationsprozess in verschiedene Schritte zu unterteilen, aber ich verstehe nicht, warum jeder einzelne Codierer auf diesem Planeten immer wieder dieselben drei Befehle schreiben muss, um nur einen einzigen Job zu erledigen. Aus meiner Sicht wäre es absolut sinnvoll, ein ./install.shSkript automatisch mit dem Quellcode zu liefern, der den folgenden Text enthält:

#!/bin/sh
./configure
make
make install

Warum sollten die Leute die 3 Schritte separat machen?

Weil jeder Schritt andere Dinge tut

Bereiten Sie die (Setup-) Umgebung für das Erstellen vor

./configure

Dieses Skript enthält viele Optionen, die Sie ändern sollten. Wie --prefixoder --with-dir=/foo. Das heißt, jedes System hat eine andere Konfiguration. ./configureÜberprüft auch , ob Bibliotheken fehlen, die installiert werden sollen. Wenn hier etwas nicht stimmt , wird Ihre Anwendung nicht erstellt . Aus diesem Grund haben Distributionen Pakete, die an verschiedenen Orten installiert sind, da jede Distribution der Meinung ist, dass es besser ist, bestimmte Bibliotheken und Dateien in bestimmten Verzeichnissen zu installieren. Es soll laufen ./configure, aber in der Tat sollten Sie es immer ändern.

Schauen Sie sich zum Beispiel die Arch Linux-Paketseite an . Hier sehen Sie, dass jedes Paket einen anderen Konfigurationsparameter verwendet (vorausgesetzt, es werden Autotools für das Build-System verwendet).

Aufbau des Systems

make

Dies ist eigentlich make allstandardmäßig. Und jede Marke hat andere Aktionen zu tun. Einige erstellen, andere führen Tests nach dem Erstellen durch, andere checken aus externen SCM-Repositorys aus. Normalerweise müssen Sie keine Parameter angeben, aber einige Pakete führen sie wieder anders aus.

Auf dem System installieren

make install

Dadurch wird das Paket an der mit configure angegebenen Stelle installiert. Wenn Sie möchten, können Sie angeben ./configure, dass auf Ihr Home-Verzeichnis verwiesen werden soll. Viele Konfigurationsoptionen zeigen jedoch auf /usroder /usr/local. Das heißt, Sie müssen dann tatsächlich verwenden, sudo make installda nur root Dateien nach / usr und / usr / local kopieren kann.

Jetzt sehen Sie, dass jeder Schritt eine Voraussetzung für den nächsten Schritt ist. Jeder Schritt ist eine Vorbereitung, damit die Dinge problemlos funktionieren. Distros verwenden diese Metapher, um Pakete zu erstellen (wie RPM, Deb usw.).

Hier sehen Sie, dass jeder Schritt tatsächlich einen anderen Zustand hat. Deshalb haben Paketmanager unterschiedliche Wrapper. Unten finden Sie ein Beispiel für einen Wrapper, mit dem Sie das gesamte Paket in einem Schritt erstellen können. Denken Sie jedoch daran, dass jede Anwendung einen anderen Wrapper hat (tatsächlich haben diese Wrapper einen Namen wie spec, PKGBUILD usw.):

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

Hier kann man Autotools verwenden, das heißt ./configure, makeund make install. Aber ein anderer kann SCons, Python-bezogenes Setup oder etwas anderes verwenden.

Wie Sie sehen, erleichtert die Aufteilung jedes Status die Wartung und Bereitstellung erheblich, insbesondere für Paketbetreuer und Distributionen.

Erstens sollte es sein, ./configure && make && make installda jeder vom Erfolg des ersteren abhängt. Ein Teil des Grundes ist die Evolution und ein Teil des Grundes ist die Bequemlichkeit für den Entwicklungsworkflow.

Ursprünglich Makefileenthielten die meisten s nur die Befehle zum Kompilieren eines Programms, und die Installation wurde dem Benutzer überlassen. Eine zusätzliche Regel ermöglicht es make install, die kompilierte Ausgabe an einem Ort zu platzieren, der möglicherweise korrekt ist. Es gibt immer noch viele gute Gründe, warum Sie dies möglicherweise nicht tun möchten, einschließlich der Tatsache, dass Sie nicht der Systemadministrator sind und es überhaupt nicht installieren möchten. Wenn ich die Software entwickle, möchte ich sie wahrscheinlich nicht installieren. Ich möchte einige Änderungen vornehmen und die Version in meinem Verzeichnis testen. Dies wird noch ausgeprägter, wenn mehrere Versionen herumliegen.

./configuregeht und erkennt, was in der Umgebung verfügbar ist und / oder vom Benutzer gewünscht wird, um zu bestimmen, wie die Software erstellt werden soll. Dies muss sich nicht sehr oft ändern und kann oft einige Zeit dauern. Auch hier lohnt es sich nicht, ständig neu zu konfigurieren, wenn ich Entwickler bin. Noch wichtiger ist make, dass beim erneuten Ausführen von Zeitstempeln zum erneuten Erstellen von Modulen die configureMöglichkeit besteht, dass sich Flags ändern. Einige der Komponenten in meinem Build werden jetzt mit einem Satz von Flags und andere mit einem anderen Satz von Flags kompiliert, was dazu führen kann anderes, inkompatibles Verhalten. Solange ich nicht erneut ausführe configure, weiß ich, dass meine Kompilierungsumgebung dieselbe bleibt, auch wenn ich meine Quellen ändere. Wenn ich es noch einmal mache configure, sollte ich es tunmake clean Entfernen Sie zunächst alle erstellten Quellen, um sicherzustellen, dass die Elemente einheitlich erstellt werden.

Der einzige Fall, in dem die drei Befehle hintereinander ausgeführt werden, ist, wenn Benutzer das Programm installieren oder ein Paket erstellt wird (z. B. Debians Debuild oder RedHats RPMbuild). Und das setzt voraus, dass die Verpackung eine Ebene erhalten kann configure, was bei Verpackungen normalerweise nicht der Fall ist, wenn dies zumindest --prefix=/usrerwünscht ist. Und Pacakger müssen sich bei der Arbeit gerne mit falschen Wurzeln auseinandersetzen make install. Da es viele Ausnahmen gibt, ./configure && make && make installwäre es für viele Leute, die dies viel häufiger tun, unpraktisch , die Regel zu erstellen!

Erstens findet ./configure nicht immer alles, was es benötigt, oder in anderen Fällen findet es alles, was es benötigt, aber nicht alles, was es verwenden könnte. In diesem Fall möchten Sie etwas darüber wissen (und Ihr Skript ./install.sh würde trotzdem fehlschlagen!). Das klassische Beispiel für Nicht-Fehler mit unbeabsichtigten Konsequenzen ist aus meiner Sicht das Kompilieren großer Anwendungen wie ffmpeg oder mplayer. Diese verwenden Bibliotheken, wenn sie verfügbar sind, kompilieren jedoch trotzdem, wenn dies nicht der Fall ist, und lassen einige Optionen deaktiviert. Das Problem ist, dass Sie später feststellen, dass es ohne Unterstützung für das eine oder andere Format kompiliert wurde, sodass Sie zurückgehen und es wiederholen müssen.

Eine andere Sache, die ./configure etwas interaktiv macht, besteht darin, Ihnen die Möglichkeit zu geben, anzupassen, wo auf dem System die Anwendung installiert wird. Unterschiedliche Distributionen / Umgebungen haben unterschiedliche Konventionen, und Sie möchten sich wahrscheinlich an die Konvention auf Ihrem System halten. Möglicherweise möchten Sie es auch lokal installieren (ausschließlich für sich selbst). Traditionell werden die Schritte ./configure und make nicht als root ausgeführt, während make install (sofern es nicht nur für Sie selbst installiert ist) als root ausgeführt werden muss.

Bestimmte Distributionen stellen häufig Skripte bereit, die diese ./install.sh-Funktionalität verteilungsabhängig ausführen - z. B. Quell-RPMs + Spezifikationsdatei + RPMbuild oder Slackbuilds .

(Fußnote: Davon abgesehen stimme ich zu, dass ./configure; make; make install; extrem langweilig werden kann.)

configure kann fehlschlagen, wenn festgestellt wird, dass Abhängigkeiten fehlen.

makeführt ein Standardziel aus, das erste, das im Makefile aufgeführt ist. Oft ist dieses Ziel all, aber nicht immer. Sie könnten es also nur, make all installwenn Sie wüssten, dass dies das Ziel ist.

So ...

#!/bin/sh

if ./configure $*; then
  if make; then
    make install
  fi
fi

oder:

./configure $* && ./make && ./make install

Das $*ist enthalten, weil man oft Optionen dafür bereitstellen muss configure.

Aber warum nicht einfach die Leute es selbst machen lassen? Ist das wirklich so ein großer Gewinn?