it-swarm.com.de

Warum sollten Makefiles ein "Installations" -Ziel haben?

Aus der Welt von C und C++ stammend, haben die meisten Build-Systeme ein install -Ziel, insbesondere Makefiles (wo es von GNU empfohlen zum Beispiel ist) oder CMake . Dieses Ziel kopiert die Laufzeitdateien (ausführbare Dateien, Bibliotheken, ...) im Betriebssystem (z. B. in C:\Program Files\ Unter Windows).

Das fühlt sich wirklich hackig an, da es für mich nicht in der Verantwortung des Build-Systems liegt, Programme zu installieren (was eigentlich in der Verantwortung des Betriebssystems/Pakets liegt Manager). Dies bedeutet auch, dass das Build-System oder das Build-Skript die Organisation der installierten Programme kennen muss, mit Umgebungsvariablen, Registrierungsvariablen, Symlinks, Berechtigungen usw.

Build-Systeme sollten bestenfalls ein release -Ziel haben, das ein installierbares Programm ausgibt (z. B. .deb Oder .msi), Und dann das Betriebssystem bitten, dieses Programm zu installieren . Außerdem kann der Benutzer deinstallieren, ohne make uninstall Eingeben zu müssen.

Meine Frage: Warum empfiehlt das Build-System normalerweise, ein install -Ziel zu haben?

18
Synxis

Viele Build-Skripte oder Makefiles haben ein Installationsziel, weil sie erstellt wurden, bevor es Paketmanager gab, und weil viele Systeme auch heute noch keine Paketmanager haben. Außerdem gibt es Systeme, in denen make install eigentlich ist die bevorzugte Art, Pakete zu verwalten.

23
Jörg W Mittag

Ein makefile hat möglicherweise kein install Ziel, und was noch wichtiger ist, Sie können Programme haben, die nicht einmal installierbar sein sollen (z. B. weil sie aus ihrem Build-Verzeichnis ausgeführt werden sollen oder weil sie ausgeführt werden können überall installiert). Das Ziel install ist nur eine Konvention für übliche makefile- s.

Für viele Programme müssen jedoch externe Ressourcen ausgeführt werden (z. B. Schriftarten, Datenbanken, Konfigurationsdateien usw.). Und ihre ausführbare Datei macht oft eine Hypothese über diese Ressourcen. Zum Beispiel würde Ihre bash Shell im Allgemeinen eine Initialisierungsdatei von /etc/bash.bashrc Usw. lesen. Diese Ressourcen befinden sich im Allgemeinen im Dateisystem (siehe hier (7) für Konventionen über die Dateihierarchie) und den Standarddateipfad wird in Ihrer ausführbaren Datei erstellt.

Versuchen Sie, Strings (1) auf den meisten ausführbaren Dateien Ihres Systems zu verwenden. Sie finden heraus, welche Dateipfade ihm bekannt sind.

Übrigens, für viele GNU Programme, die autoconf verwenden, könnten Sie make install DESTDIR=/tmp/destdir/ Ausführen, ohne root zu sein. Dann wird /tmp/destdir/ Mit den Dateien gefüllt, die sollten später verpackt werden.

FWIW, ich neige dazu zu glauben, dass mein bismon (GPLv3 + lizenziertes) Programm (beschrieben in meinem bismon-chariot-doc.pdf Bericht) nicht "installiert" werden kann; Ich bin mir nicht sicher, ob ich das beweisen kann, und ich kann mir nicht vorstellen, wie ich dieses Programm installierbar machen könnte.

Es gibt mehrere Gründe, die mir in den Sinn kommen.

  • Viele Paketerstellungssoftware - beispielsweise das Build-System Debian und auch die IIRC-Drehzahl - erwarten bereits vom Build-Skript, dass das Programm in einem speziellen Unterverzeichnis "installiert" wird. Es wird also durch Abwärtskompatibilität in beide Richtungen angetrieben.
  • Ein Benutzer möchte die Software möglicherweise in einem lokalen Bereich installieren, z. B. in $HOME Verzeichnis. Nicht alle Paketmanager unterstützen dies.
  • Möglicherweise gibt es noch Umgebungen ohne Pakete.
3
max630

Nun, Anwendungsentwickler sind diejenigen, die wissen, wohin jede Datei gehen soll. Sie könnten dies in der Dokumentation belassen und die Paketbetreuer das lesen lassen und für jedes Paket ein Skript erstellen. Möglicherweise interpretieren die Paketbetreuer die Dokumentation falsch und müssen das Skript debuggen, bis es funktioniert. Das ist ineffizient. Für den Anwendungsentwickler ist es besser, ein Skript zu schreiben, um die von ihm geschriebene Anwendung ordnungsgemäß zu installieren.

Er könnte ein Installationsskript mit einem beliebigen Namen schreiben oder es vielleicht Teil der Prozedur eines anderen Skripts machen. Mit dem Standardinstallationsbefehl make install (Eine Konvention, die älter ist als Paketmanager) ist es jedoch sehr einfach geworden, Pakete zu erstellen. Wenn Sie sich die PKGBUILD-Vorlage zum Erstellen von Archlinux-Paketen ansehen, können Sie sehen, dass die Funktion, die tatsächlich Pakete erstellt, einfach einen make DESTDIR="$pkgdir/" install Ausführt. Dies funktioniert wahrscheinlich für die meisten Pakete und wahrscheinlich mehr mit ein wenig Modifikation. Da make (und die Autotools) Standard sind, ist das Verpacken wirklich sehr, sehr einfach.

1
JoL

Ein Grund, der nicht erwähnt wird, ist, dass Sie häufig nicht die aktuelle Version der Software oder eine modifizierte Version der Software verwenden. Der Versuch, ein benutzerdefiniertes Paket zu erstellen, ist nicht nur mehr Arbeit, sondern kann auch zu Konflikten mit aktuell erstellten und verteilten Paketen führen. Im Open Source Code passiert dies häufig, insbesondere wenn in zukünftigen Versionen, die Sie verwenden, wichtige Änderungen vorgenommen werden.

Angenommen, Sie verwenden das Open Source-Projekt FOO, das derzeit auf Version 2.0.1 ausgeführt wird, und Sie verwenden Version 1.3.0. Sie möchten nichts darüber hinaus verwenden, da Version 2.0.0 nicht mit dem kompatibel ist, was Sie gerade tun, aber es gibt eine einzige Fehlerbehebung in 2.0.1, die Sie dringend benötigen. Mit der Option make install Können Sie die geänderte 1.3.0-Software installieren, ohne sich um die Erstellung eines Pakets und die Installation auf Ihrem System kümmern zu müssen.

1
Dom

Linux-Distributionen trennen die Programmwartung im Allgemeinen von der Paketwartung. Ein Build-System, das die Paketerzeugung integriert, würde Programmbetreuer dazu zwingen, auch die Paketwartung durchzuführen.

Dies ist normalerweise eine schlechte Idee. Distributionen verfügen über eine große Infrastruktur, um die interne Konsistenz zu überprüfen, Binärdateien für mehrere Zielplattformen bereitzustellen, kleine Änderungen vorzunehmen, um eine bessere Integration in den Rest des Systems zu ermöglichen, und Benutzern, die Fehler melden, eine konsistente Erfahrung zu bieten.

Um Pakete direkt aus einem Build-System zu generieren, müssten Sie die gesamte Infrastruktur entweder integrieren oder umgehen. Die Integration wäre eine Menge Arbeit für einen fragwürdigen Nutzen, und die Umgehung würde zu einer schlechteren Benutzererfahrung führen.

Dies ist eines der "Top-of-the-Food-Chain" -Probleme, die für Mehrparteiensysteme typisch sind. Wenn Sie mehrere komplexe Systeme haben, muss es eine klare Hierarchie geben, welches System für die Koordination aller anderen Systeme verantwortlich ist.

Bei der Verwaltung der Softwareinstallation ist der Paketmanager diese Komponente. Er führt das Build-System des Pakets aus, führt die Ausgabe über eine praktische Schnittstelle ("Dateien in einem Verzeichnis nach einem Installationsschritt") aus, generiert ein Paket und bereitet es vor es zum Hochladen in ein Repository.

Der Paketmanager steht hier in der Mitte zwischen dem Build-System und dem Repository und ist in der besten Position, um sich gut in beide zu integrieren.

Möglicherweise haben Sie bemerkt, dass nur wenige der über npm verfügbaren JavaScript-Pakete auch über apt verfügbar sind. Dies liegt hauptsächlich daran, dass die JavaScript-Benutzer entschieden haben, dass npm und das zugehörige Repository würde die Spitze ihrer Nahrungskette sein, was es nahezu unmöglich machte, diese Pakete als Debian-Pakete zu versenden.

Mit meinem Debian Developer Hut auf: Wenn Sie Open Source-Software veröffentlichen, überlassen Sie die Verpackung bitte den Distributionsbetreuern. Das spart Ihnen und uns viel Arbeit.

1
Simon Richter