make hat mich ausgetrickst [gelöst]

[dakuan]

Nach einer Programmänderung gestern wollte ich ein selbstgestricktes Programm heute systemweit installieren. Das übliche

Code: Alles auswählen

sudo make install

hat mich dann aber überrascht. Da wurden zuvor noch einige Dateien neu übersetzt. Ich hatte da nur Kommentare ergänzt.

Mit war nicht klar, dass make bei "install" die Quelldateien nochmal überprüft. Dadurch gehören mir jetzt einige .o Dateien nicht mehr. Das ist zwar kein Drama, aber lästig.

Ist das grundsätzlich so, oder kann ich die Makedatei so gestalten, dass das nicht passiert?

[Meillo]

Das ist immer so. Make prueft welche Quelldateien neuer sind als die aus ihnen erzeugten kompilierten Objekte. Immer wenn die Ausgangsdatei neuer ist als die Zieldatei, dann wird sie neu erzeugt.

Wenn du die Zieldateien mit `touch' anfasst, dann sind sie neuer als die Ausgangdatei und werden nicht mehr uebersetzt.

Natuerlich kannst du auch das Makefile aendern und die Abhaengigkeiten entfernen. In der Zeile von `install' musst du das, was hinter dem Doppelpunkt steht entfernen. (Zumindest sollte das bei einem recht normal aufgbauten Makefile funktionieren.)

[JTH]

Ist das grundsätzlich so […]

Was die einzelnen make-Targets (install, clean, all, …) machen (und wie sie überhaupt heißen), ist nirgendwo streng erzwungen, das ist hauptsächlich Konvention. Bei GNU-Programmen z.B. kann man sich drauf verlassen, dass sie das tun, was man erwartet.

[…] oder kann ich die Makedatei so gestalten, dass das nicht passiert?

Ganz generell: ja. Ob das sinnvoll (vermutlich eher nicht) und wenig Aufwand ist, hängt von dem nicht genauer benannten Programm ab.

Mit war nicht klar, dass make bei "install" die Quelldateien nochmal überprüft.

Wenn das install-Target vom eigentlichen, vorherigen Target zum Bauen des Programms abhängt, kann das vorkommen. Letzteres hängt normalerweise von den einzelnen Quellcodedateien ab. Und wenn sich die – auch nur durch Kommentare – verändert haben, wird alles geänderte neu kompiliert.

[dakuan]

Ok, dann muss ich wohl besser aufpassen oder immer ein einfaches make voran stellen.

Hier mal das Ende der Makedatei:

Code: Alles auswählen

install: $(TARGET)
	install $(TARGET) ${PROGDIR}
	@cp -u $(TARGET).png ${ICONDIR}
	@cp -u $(TARGET).desktop ${DESKTOPDIR}
	@mkdir -p $(FILESDIR)
	@cp -u frame_mask.png $(FILESDIR)
	@cp -u $(TARGET).cfg $(FILESDIR)

uninstall:
	@rm ${DESKTOPDIR}$(TARGET).desktop
	@rm ${ICONDIR}$(TARGET).png
	@rm ${PROGDIR}$(TARGET)
	@rm $(FILESDIR)frame_mask.png
	@rm $(FILESDIR)$(TARGET).cfg
	@rmdir $(FILESDIR)

Zum Target gehören etwa ein Dutzend Dateien. Das $(TARGET) da raus zu nehmen macht wohl wirklich keinen Sinn.

[Meillo]

Hier mal das Ende der Makedatei:

Code: Alles auswählen

install: $(TARGET)
	install $(TARGET) ${PROGDIR}
	@cp -u $(TARGET).png ${ICONDIR}
	@cp -u $(TARGET).desktop ${DESKTOPDIR}
	@mkdir -p $(FILESDIR)
	@cp -u frame_mask.png $(FILESDIR)
	@cp -u $(TARGET).cfg $(FILESDIR)

Zum Target gehören etwa ein Dutzend Dateien. Das $(TARGET) da raus zu nehmen macht wohl wirklich keinen Sinn.

Warum nicht? Das wuerde genau das erreichen was du willst: Dann hast du das Bauen der Anwendung getrennt von ihrer Installation. Du musst dann halt selber darauf achten, dass du die Anwendung auch wirklich gebaut hast, bevor du sie installierst. Andernfalls bekommst du halt ein paar Fehlermeldungen.

Ein #-Zeichen vor das $(TARGET) und du hast deinen Wunsch umgesetzt.


Edit: Im Uebrigen trennt man das Bauen und das Installieren sowieso, weil man ueblicherweise mit Userrechten baut und dann mit root-Rechten installiert.

[dakuan]

Warum nicht? Das wuerde genau das erreichen was du willst: Dann hast du das Bauen der Anwendung getrennt von ihrer Installation. Du musst dann halt selber darauf achten,

Das auseinander zu halten, sollte nicht das Problem sein.

Edit: Im Uebrigen trennt man das Bauen und das Installieren sowieso, weil man ueblicherweise mit Userrechten baut und dann mit root-Rechten installiert.

Genau, Ich bin davon ausgegangen das dies automatisch immer so ist.

Ich muss allerdings zugeben, das ich mich mit den Makefiles nicht besonders gut auskenne. Der Ursprung meiner Makefiles stammt aus einem Beispiel von der FLTK Seite, was ich dann immer bei Bedarf erweitert hatte.. Aber das ist jetzt erst mein drittes Projekt, wo ich auch die endgültige Installation mit make realisiert hatte (wegen der Icons und der .desktop Dateien).

Ich probiere Deinen Tipp morgen mal aus. Zu so später Stunde sollte man keine Experimente mehr machen, zumal wenn nebenher im TV noch Snooker übertragen wird.

Du musst dann halt selber darauf achten, dass du die Anwendung auch wirklich gebaut hast, bevor du sie installierst.

Das ist eigentlich kein Problem. Aber sollte man da noch ein Hinweistext als Aufmerksamkeitserreger einbauen?

[Meillo]

[...] zumal wenn nebenher im TV noch Snooker übertragen wird.

Snooker schaue ich auch gerne. Wer spielt denn gegen wen?

Du musst dann halt selber darauf achten, dass du die Anwendung auch wirklich gebaut hast, bevor du sie installierst.

Das ist eigentlich kein Problem. Aber sollte man da noch ein Hinweistext als Aufmerksamkeitserreger einbauen?

Besser als erste Zeile unter `install' einen Text der prueft, ob das Programm gebaut ist und sonst abbricht. Vielleicht in der Art (ungetestet):

Code: Alles auswählen

@test -f $(TARGET) || { echo "Run 'make all' first" >&2; exit 1; }

(Die Zeile muss natuerlich auch mit einem Tab eingerueckt werden. Ich weiss nicht, ob das so funktioniert, aber es koennte vielleicht so gehen. )

[eggy]

@Meillo: hilft nicht, weil make ja erkennen soll, ob nen Target veraltet ist.
D.h. im ungünstigsten Fall, baut man, bemerkt nen Fehler, repariert den, und installiert dann doch den alten Build.

Wenn das Makefile nur für den Privatgebrauch ist, wäre es vermutlich "besser" das sudo direkt in den jeweiligen Abschnitt zu schreiben, oder in den Bauabschnitten auf "whoami not root" zu testen.

Sich den sudo Blödsinn einfach abgewöhnen und gut, wäre aber vermutlich die einzige richtige Lösung

[Meillo]

@Meillo: hilft nicht, weil make ja erkennen soll, ob nen Target veraltet ist.
D.h. im ungünstigsten Fall, baut man, bemerkt nen Fehler, repariert den, und installiert dann doch den alten Build.

Aber genau das war doch der urspruengliche Wunsch: Beim Installieren soll nur installiert werden, ohne ggf. irgendetwas neu zu bauen. Ich habe das so verstanden, dass das Bauen und das Installieren voneinander entkoppelt werden sollen. Dies erreicht man, indem man beim `install'-Target die Abhaengigkeit auf das Buildergebnis $(TARGET) entfernt.

Oder habe ich etwas falsch verstanden?

[eggy]

Passt schon, aber so ganz sinnvoll ist es halt nicht.
Vielleicht kann man was mit priviledgedrop und selbstaufrufendem Make basteln?
Oder nen clean hinterherschicken, oder die zumindest nen chown $user?

[dakuan]

So, ich habe das eben ausprobiert. Es funktioniert soweit.

Allerdings sehe ich das der depend: Zweig noch abgearbeitet wird. Das kann man als Hinweis deuten, das möglicherweise noch Handlungsbedarf besteht. Ansonsten will ich an der Stelle nicht zu viel Aufwand treiben. Die Idee mit dem Hinweistext hatte ich eigentlich schon gestern Abend wieder verworfen.

Wenn das Makefile nur für den Privatgebrauch ist, ...

Ja, ist für den Privatgebrauch. Einmal weil meine Probleme zu speziell sind (wer braucht denn sowas?), und dann höre ich von Linux-Fundamentalisten immer, dass meine Art von Programmen unerwünscht sind.

Und das mit "sudo " finde ich gar nicht so schlecht, aber das hängt davon ab, woran man gerade arbeitet. Um beide Möglichkeiten zu haben, habe ich mir auch bei Ubuntu einen echten root account eingerichtet.

Snooker schaue ich auch gerne. Wer spielt denn gegen wen?

Momentan läuft noch die die WM, da ist jetzt jeden Tag was los: Turnierplan

[eggy]

Code: Alles auswählen

install:
	# ...
	@chown $$SUDO_USER datei 

Man sollte vorher noch testen, ob man überhaupt root ist und ob SUDO_USER gesetzt ist (und dann vielleicht auch besser gleich SUDO_UID nehmen) und den Befehl nur dann ausführen, falls man wirklich im sudo ist. So gibt's zumindest da keine komischen Überraschungen.

Edit: Nachtrag: durch sudo werden einige Umgebungsvariablen gesetzt, die es sonst nicht geben sollte: SUDO_COMMAND, SUDO_GID, SUDO_UID, SUDO_USER, siehe man sudo.

[Meillo]

Ich bin mir nicht sicher, ob ich ganz mitkomme, aber `install' sollte nicht erzwingen, dass man root ist. Mit einem angepassten Prefix sollte man auch ins Homeverzeichnis installieren koennen, oder wenn ich /usr/local fuer die Gruppe schreibbar ist und ich Mitglied der Gruppe bin, dann kann ich dort auch als User hininstallieren. Moeglicherweise sind das heutzutage nicht mehr die gaengigsten Szenarien, aber sie sind weiterhin legitim. Ich finde, dass die ganze Rechte- und User-Sachen nicht Teil von (normalen) Makefiles sein, sondern ausserhalb davon passieren sollten. Wenn die noetigen Rechte fehlen, schlaegt der cp-Befehl im `install'-Target halt fehl.

[eggy]

Ich wär normalerweise auch dagegen soviel unberechenbaren Krams in nem Makefile zu haben, aber da es hier "nur für mich" ist, kann man auch mal pragmatisch sein.
Richtiger wäre eh, das zu ordentlich zu paketieren und nur via Paketverwaltung zu installieren

[dakuan]

Richtiger wäre eh, das zu ordentlich zu paketieren und nur via Paketverwaltung zu installieren

Für mich als nicht-Profi ist das zu kompliziert.

Früher war ich mit SuSE unterwegs und demnächst wird wohl noch Arch Linux dazukommen. Das wären dann 2 Paketsysteme in die ich einsteigen müsste. Und in C++ bin ich auch noch nicht sattelfest. Ich habe da noch genug andere Baustellen.

Ich habe hier mehrere PCs auf denen ich meine Programme teste. Da ist die Installation per make schon eine gute Hilfe.

[DeletedUserReAsG]

Für mich als nicht-Profi ist das zu kompliziert.

checkinstall wäre ’n guter Kompromiss – das kann aus dem Ergebnis von make install ein Paket bauen, welches man dann über das Paketsystem handhaben kann.

[dakuan]

Checkinstall hatte ich vor etlichen Jahren einmal verwendet um unter Ubuntu einen Nvidia Grafiktreiber zu installieren. Damals war ich aber hauptsächlich mit Windows unterwegs. Später habe ich dann gelesen, dass das eine schreckliche Krücke sei (keine Ahnung warum).

Ob das in meiner aktuellen Situation eine Option ist, kann ich noch nicht beurteilen. Ich verwende das Toolkit FLTK und habe es aus dem Quelltext installiert, weil die Version aus den Paketquellen zu alt ist. Ich benötige einige neuere Features. Außerdem habe ich darin 3 Bugs entdeckt, die meine Programme zum Absturz bringen. Die Fixes sind nur in neueren Versionen vorhanden (1.4.0+). Ob checkinstall das berücksichtigt kann ich momentan nicht beurteilen.

Dazu muss man wissen, das bei Debian & Ubuntu für FLTK eine libfltk verwendet wird, während bei der Version aus den Quelltexten alle FLTK-Abhängigkeiten statisch ein-gelinkt werden (sofern man bei der Erstellung nicht eingreift).

Ob das bei einer "normalen" Packetierung oder bei checkinstall eine Rolle spielt, kann ich nicht beurteilen. Ich bin ja eher der Software Bastler und nicht der -Techniker.

[heisenberg]

checkinstall hat mit Deinem Kompilierungsvorgang recht wenig zu tun.

Das was es tut, ist dass es das Installationsscript(Per Vorgabe "make install") überwacht und schaut, was dieses tut. D. h. welche Dateien werden im System installiert). Anschließend baut es ein Paket daraus.

Als Krücke wurde es wahrscheinlich deshalb bezeichnet, weil es halt kein ordentliches Paket erstellt, dessen Konfiguration irgendwelchen Qualtitätsrichtlinien an Pakete entspricht. Es ist in der Hinsicht halt Quick-And-Dirty. Aber für Dein Anliegen bestimmt hilfreich. Es hilft dabei, das Paket wieder rückstandsfrei zu entfernen.

[dakuan]

Danke für die Erläuterungen. Wenn man das weiß, kann man sich vorstellen, woher der Name checkinstall kommt.

Aber die rückstandslose Entfernung habe ich ja in meiner make Datei unter "uninstall:" vorgesehen, was bei meinen Tests auch funktioniert hat. Nur die Config im Userverzeichniss bleibt zurück.

Aber checkinstall kann meine Probleme nicht alle lösen. Ich schiebe z.B. den Quellcode zwischen einem 64 und 32 Bit System hin und her. Da erlebe ich immer wieder mal Überraschungen.

[atarixle]

Genau wie bei Debian-Paketen, gibt es auch bei Quell-Archiven mehr oder weniger gute Qualität.

So habe ich früher auf einem älteren Debian grundsätzlich wine aus den Quellen installiert und mich dort auch sehr gut auf make uninstall verlassen können.

Entgegen aller Empfehlungen hatte die Installation einer neuen Version von wine über die alte aber keine negativen Auswirkungen - die Versionsfortschritte waren immer im Minor-Bereich.

Das Quellpaket von cc65 lässt sich sogar ohne ./configure bauen, ohne auch nur eine Warnung auszugeben - von Mac OS X Leopard (PowerPC) bis hin zu Catalina (x86_64) und natürlich unter allen debian-Varianten, die ich betreibe.

Was ich eigentlich zum Thema beitragen wollte: Danke dafür, davon zu berichten, was passiert, sudo make install zuerst ausführt. Dass dann einem die gebauten Dateien nicht gehören und deshalb der Zwischenschritt über make (ohne sudo und install) gemacht wird, hatte ich irgendwie nie auf dem Schirm. Da hab ich wieder was gelernt (oder begriffen).

[Meillo]

Was ich eigentlich zum Thema beitragen wollte: Danke dafür, davon zu berichten, was passiert, sudo make install zuerst ausführt. Dass dann einem die gebauten Dateien nicht gehören und deshalb der Zwischenschritt über make (ohne sudo und install) gemacht wird, hatte ich irgendwie nie auf dem Schirm. Da hab ich wieder was gelernt (oder begriffen).

Das ist nicht der einzige Grund. Generell sollte man stets die geringsten Rechte verwenden, die noetig sind. Zum Kompilieren von Software sind keine root-Rechte noetig. Es ist nicht noetig, dass all der Code, der beim Kompilieren aufgerufen wird (was ggf. eine ganze Menge sein kann) mit root-Rechten laeuft. Auch darum sollte man als User kompilieren. Zum Installieren dagegen braucht man normalerweise root-Rechte, das laesst sich halt nicht aendern. Falls man bei Fremdcode im Makefile pruefen will was beim Aufruf von `make' mit root-Rechten ausgefuehrt werden wird, so ist das install-Target meist deutlich uebersichtlicher als wenn man allen Kompiliercode auch noch durchschauen muss.

[dakuan]

Entgegen aller Empfehlungen hatte die Installation einer neuen Version von wine über die alte aber keine negativen Auswirkungen - die Versionsfortschritte waren immer im Minor-Bereich.

Das war bei meinem aktuellen Projekt leider nicht ganz so. Aber bei einer Versionsnummer von 0.51 ist klar, das da noch Bewegung ist. Aufgrund neuer Erkenntnisse musste ich das Format der Konfigurationsdatei ändern. Da müsste dann auch die lokale Version in $HOME erneuert werden.

Ich habe mir mehrere Quelltexte besorgt, aus Neugier, aber nur FLTK wirklich daraus installiert. Dabei habe ich auch mehrfach die Konfiguration geändert, um die neuen Features nutzen zu können. Hat bei FLTK immer funktioniert.

Allerdings war mir dabei am Anfang nicht klar, dass sich dadurch das ABI ändert und meine eigenen Programme nach Veränderungen abstürzen. Ich konnte das dann meistens durch ein beherztes

Code: Alles auswählen

rm *.o

lösen. Nachdem ich jetzt noch einiges über make gelesen habe, ist mit klar, das mir der Zweig clean: fehlt. Im Buch "Linux-UNIX Programmierung" wurde das zwar erwähnt, aber nicht wirklich wozu das gut ist.