hddtemp für YaDD

[GetAway]

Kann die ide-apps.mk so angepasst werden, das beim bauen von hddtemp
das Binary automatisch auch in /sbin des YaDD landet? Danke schon mal.

[dwilx]

Wird das nicht schon mit make hddtemp also auch von make ide_apps gemacht?

[GetAway]

Aso, danke für den Hinweis. Hatte bisher immer nur make flash-hddtemp ausgeführt.

Das reicht z.B auch bei make flash-openntpd um ihn im Flash und im YaDD zu haben.
Wieso werden da unterschiede gemacht. Es gibt doch eigentlich keinen Grund
Applikationen die man für's Flash baut nicht auch gleich im YaDD zu haben, oder?

[dwilx]

So wie ich das sehe ist das bei den anderen targets auch so. Dann scheint beim hddtemp target etwas nicht zu passen.

[rhabarber1848]

Das ist im CVS inkonsistent, weil es zwei Denkschulen gibt:

1. make foo nur für yadd, make flash-foo nur für flash,
wer beides will, muss zweimal kompilieren
2. flash-foo hat foo als Abhängigkeit und kopiert die
Binary aus dem Yadd- ins Flash-Verzeichnis

Wir sollten uns für einen Weg entscheiden und diesen konsequent
verfolgen, die Makefiles werden dadurch auch übersichtlicher.
Methode 1 gilt afaics neben hddtemp auch für hdparm, e2fsprogs,
xfsprogs und smartmontools.

Bei reiserfsprogs habe ich es bereits nach Methode 2 durchgeführt,
gleiches galt bereits für fdisk (utillinux) und dosfstools.

Nun kann es mal sein, dass eine Binary für Flash-Images mit anderen
Parametern kompiliert wird als für ein Yadd-Image, dann muss
weiterhin Methode 1 gelten um doppeltes Kompilieren für Flash-only-
User zu vermeiden. Dieser Fall ist mir bei schnellem Durchblättern
von ide-apps.mk aber nicht aufgefallen.
Deshalb bevorzuge ich Methode 2.

[Barf]

Jetzt kommen wir zu eine Art Grundsatzfragen. Ich habe schon in 2006 folgendes geschrieben:

Benutze "make install", mopse nicht einzelne Files!

In der Vergangenheit hat das Tuxbox Makefile die Komponente zuerst in $(targetprefix) installiert, und dann die Imageverzeichnissen durch Kopieren der einzelnen Files von der $(targetprefix) Hierarchie erstellt. Dieses ist nicht sehr gute Softwaretechnik. Zuerst gehört das Know-how bzgl. Installation des Paket dem Makefile des Pakets, und soll nicht einem allgemeinen Makefile sitzen, das einfach einzelne Files rüberkopiert. Wenn dieses Paket sich ändert, z.B. dadurch eine Konfiguration File zugefügt oder gelöscht wird, wird es auch notwendig, in das globale Makefile zu ändern.

Es ist häufig der Fall, dass das Makefile, das dem Paket gehört, include-Files, (statische) Bibliotheken, Info-Files etc. installiert, die nicht auf einem enbedded System mit beschränktem Speicher gewünscht sind. Die korrekte Lösung zu diesem (wirklichen!) Problem würde wurde sein, das Makefile des Pakets zu ändern, entweder, um ein flashinstall-Target zu schreiben, oder das Makefile mit einem Parameter wie installsize=[full,flash] zu versehen. Wenn dieses nicht durchführbar ist, ist es meine Meinung, daß make -C ... install gefolgt vom Löschen der unerwünschten Files besser ist als das kopierend einzelne Files. Zu erwähnen ist auch, daß in dem Schritt, der die Verzeichnisse $(flashprefix)/root-gui-filesystem erzeugt, das include-verzeichnis, sowie alle statischen Bibliotheken gelöscht werden und dynamische Bibliotheken von unbenutzten Symbolen gestrippt werden.

Ich finde die Argumente genau so gülig heute wie damals. Eher gültiger, weil die moderen Rechnern schneller bauen als damals.

rhabarbers "2." ist ein Relikt von "oldmake". Man gibt (aus Faulheit) targetprefix (ckdroot) die doppelte Bedeutung als root-Dateisystem für YADD, sowei als Zwischenablage. So wird nicht Qualitätssoftware hergestellt.

Aber pragmatisch sehe ich es nicht als ein Problem, das eine generelle Lösung fordert.

[rhabarber1848]

rhabarbers "2." ist ein Relikt von "oldmake". Man gibt (aus Faulheit) targetprefix (ckdroot) die doppelte Bedeutung als root-Dateisystem für YADD, sowei als Zwischenablage.

Solange die Binaries mit denselben Parametern kompiliert werden,
macht es IHMO keinen Sinn, z.B. im Fall von

make flash-neutrino-squashfs-all yadd-neutrino

viele Pakete doppelt zu kompilieren. In diesem Sinne kann
$prefix/cdkroot neben der Yadd-Funktionalität ruhig als
Dateiquelle für Flashimages dienen.