[Trunk] vnstat (& Makefile-"SUBOPTS")

[MaxMuster]

Noch ohne es probiert zu haben:
Wenn die "SUBOPTS" raus sind, wird dann nicht das .mk-File bei einer Änderung nicht mehr aufgerufen? Wie kommen denn dann die (ggf.) "neuen", also zusätzlich gewählte, Binaries in das packages-Verzeichnis??


Jörg

 

[er13]

Es ist vielleicht gar nicht notwendig, das Makefile nochmal aufzurufen. Die Binaries von den vorigen Builds sind möglicherweise schon vorhanden und müssen lediglich aus dem Build- ins packages-Verzeichnis kopiert werden. Ich finde übrigens, dass diese $(PKG)_CONFIG_SUBOPTS Variable an ein paar Stellen falsch verwendet wird. Es werden nämlich zu viele menuconfig-Optionen als Makefile-Subopts deklariert. Dies führt dazu, dass das Paket öfter als eigentlich notwendig übersetzt wird (mit übersetzen sind dabei die beiden Schritte configure und make gemeint). Als Beispiel nehme man z.B. e2fsprogs, wird FREETZ_PACKAGE_E2FSPROGS_E2MAKING verstellt, so muss nichts neuübersetzt werden, die Binaries werden genauso sein wie vor dem Verstellen, denn diese Option FREETZ_PACKAGE_E2FSPROGS_E2MAKING hat rein gar keine Auswirkungen auf den Build-Prozess an sich, sie steuert lediglich was man ins Image kopieren möchte. Bei den beiden rausgeschmiessenen vnstat-Optionen ist es genauso...

Ich habe mir die Mühe gemacht, Makefiles aller Pakete anzuschauen. Meiner Meinung nach sind außer vnstat noch folgende Pakete von dem von cuma entdeckten Problem betroffen. Manche enthalten bereits die clean-Regeln, manche noch nicht:

• bird (keine clean-Regeln vorhanden)
• dosfstools (keine clean-Regeln vorhanden)
• dropbear (keine clean-Regeln vorhanden)
• e2fsprogs (keine clean-Regeln vorhanden) (edit)
• espeak (keine clean-Regeln vorhanden) !
• irssi (keine clean-Regeln vorhanden) (edit: hab' mich vertan, ist alles ok)
• lighttpd (keine clean-Regeln vorhanden) !
• mc (clean-Regeln vorhanden)
• nsftp (clean-Regeln vorhanden)
• openssh (clean-Regeln vorhanden)
• pciutils (clean-Regeln vorhanden)
• pppd (keine clean-Regeln vorhanden)
• samba (clean-Regeln vorhanden)
• sispmctl (clean-Regeln vorhanden) !
• subversion (keine clean-Regeln vorhanden)
• transmission (keine clean-Regeln vorhanden)
• usbutils (clean-Regeln vorhanden)
• vnstat (keine clean-Regeln vorhanden)
• xpdf (keine clean-Regeln vorhanden)

Bei den folgenden bin ich mir noch unsicher, muss mir diese genauer anschauen

• callmonitor
• hplip
• iptables
• sane-backends

Bei den mit Ausrufezeichen markierten Paketen meine ich noch ein anderes Problem entdeckt zu haben. Bei diesen ist es nämlich möglich, dass manche Files gar nicht ins Image kopiert werden, obwohl die entsprechenden menuconfig-Optionen gewählt sind. Beispiel: in menuconfig von lighttpd wähle man die Optionen zunächst so, dass keine lighttpd-module ins Image kopiert werden und übersetze lighttpd. Nun rufe man erneut make menuconfig auf und verstelle die Optionen. Man füge jetzt alle lighttpd-module hinzu und rufe make auf. Keins der dazu gewählten Module wird ins packages-Verzeichnis kopiert. Schuldig ist die $($(PKG)_MODULE_TARGET_BINARY): $($(PKG)_MODULE_BINARY) Regel. Diese ist schlicht und ergreifend falsch. Es werden mehrere Dateien kopiert, dies wird jedoch von einer einzigen (mod_access.so) abhängig gemacht. Das gleiche gilt für espeak-Regel $(ESPEAK_TARGET_BINARY): $(ESPEAK_BINARY) (nicht alle Sprachdateien werden kopiert) und für sispmctl-Regel $($(PKG)_TARGET_BINARY): $($(PKG)_BINARY) (webinterface-Dateien werden nicht ins Image kopiert, sofern man davor sispmctl übersetzt hat, ohne webinterface ausgewählt zu haben).

Irgendwie bin ich gar nicht scharf drauf, all das anzupassen, auf der anderen Seite ist es schon ein Fehler, der Aufwand wird sich hoffentlich in Grenzen halten...

p.s. Und übrigens genau dieses Problem habe ich mit dieser neuen Lösung im vorigen Beitrag von mir vermutet.

 

[olistudent]

Wir wollten das Problem dadurch lösen, dass wir neu bauen und dabei das Package Verzeichnis löschen. Das ist sicher nicht die optimale Lösung wie du festgestellt hast, aber einfach zu implementieren. Oder hab ich da jetzt ein Fall übersehen?

Deshalb auch die Subopts für die verschiedenen Binaries. Bei Paketen wie lighttpd ist es ohne "deine" Patterns fast unmöglich ein korrektes Makefile zu schreiben. Da wird man ja nie fertig.

MfG Oliver

 

[er13]

Ich habe auch nichts dagegen, das Package-Verzeichnis zu löschen, Jörg möchte nur darin seine cgi's editieren ;-)

 

[Silent-Tears]

Die cgis kann man doch aber in make/$pkg/files/... editieren?

 

[olistudent]

In packages/... sollte man nichts editieren...

MfG Oliver

 

[MaxMuster]

Aber vielleicht warten wir mal, ob sonst noch wer eine Meinung zu dem Thema hat

Auch wenn ich es noch immer nicht richtig finde, und auch das "neue" Argument mich nicht wirklich überzeugt, dass das Löschen des packages Verzeichnis Fehler im makefile behebt, halte ich mich an meine Aussage und "füge mich der Mehrheit" (sofern das überhaupt nötig ist ;-))
Es ging mir eigentlich weniger um meine "Editiererei" in dem Verzeichnis, ich finde es nur gut, wenn möglich den "eleganten" Weg zu gehen, wenn der wie hier keinen echten Aufwand bedeutet. Wir machen auf der einen Seite den ganzen Aufwand mit den .-Files im packages Ordner, auf der anderen holen wir den "Holzhammer" zum Löschen, sobald sich was ändert.
Übrigens stimme ich aus genau dem Grund auch er13 voll zu, dass auch meiner Meinung nach zu häufig ein Paket komplett neu übersetzt werden. Aber ich kann auch nachvollziehen, dass es der einfachste Weg ist, um Änderungen sicher umzusetzen und da ich es nicht ändern kann/will, hab ich da auch nix drüber zu meckern ;-).

Einen schönen Heiligen Abend und Frohe Weihnachten!

Jörg

 

[olistudent]

Was meinst du "den ganzen Aufwand mit den .-Files"? Die werden angelegt, dass man erkennt, dass die Package-Dateien kopiert sind und das nicht bei jedem Build passieren muss.
Du musst auch sehen, dass das ganze historisch gewachsen ist. Damals gab es einfach keine Pakete mit mehreren Binaries, daher wurde diese Option beim Design nicht beachtet.

Natürlich ist es mir auch lieber, wenn ein Package nur neu gebaut wird, wenn es wirklich nötig ist. Die falsche Verwendung der Subopts sollten wir auf alle Fälle beheben. Wenn wir die Funktion, dass unnötige Binaries gelöscht werden sauber als Makro hinbekommen, dann hab ich kein Problem damit, dass die Package-Dateien nicht gelöscht werden.


MfG Oliver

 

[RalfFriedl]

Auch wenn ich es noch immer nicht richtig finde, und auch das "neue" Argument mich nicht wirklich überzeugt, dass das Löschen des packages Verzeichnis Fehler im makefile behebt

Diese "Fehler" im Makefile sind in diesem Fall beabsichtigt, bzw. ergeben sich aus einer Abwägung zwischen Korrektheit und Geschwindigkeit.
Der Ideale Fall wäre, daß man make aufruft, und dann wird alles neu erstellt, was aufgrund der Änderungen neu erstellt werden muß (Korrektheit), aber auch nur das (Effizienz). Das bedeutet, daß auch alle Makefiles der einzelnen Pakete abgearbeitet werden müßten, für den Fall, daß dort Änderungen vorgenommen wurden. Das würde sehr lange dauern. Deswegen hat Alexander mal eine Abkürzung eingebaut, die das verhindert, wenn die Ziel-Datei schon existiert. Das funktioniert in den meisten Fällen gut, aber manchmal ist ein Aufruf von dirclean oder pkg-dirclean notwendig. Bei korrekten Makefiles wäre dies nicht nötig, aber dafür würde das Erstellen in vielen Fällen länger dauern.
Wenn ausschließlich Dateien aus dem source-Verzeichnis nach packages kopiert werden, sollte das nicht sonderlich lange brauchen. Und wenn dies nur für ein Paket passiert und nur dann, wenn sich eine Option dieses einen Paketes geändert hat, dann sehe ich darin kein Problem.

 

[er13]

Die falsche Verwendung der Subopts sollten wir auf alle Fälle beheben. Wenn wir die Funktion, dass unnötige Binaries gelöscht werden sauber als Makro hinbekommen, dann hab ich kein Problem damit, dass die Package-Dateien nicht gelöscht werden.

ich habe es schon angefangen, die folgenden Pakete (ohne explizite clean-Regeln und die meisten auch ohne SUBOPTS!) habe ich schon durch: bird, dosfstools, espeak, e2fsprogs, subversion, transmission, vnstat.

Wir werden aber zweigleisig fahren müssen. Ist eine menuconfig-Option als makefile-SUBOPT deklariert, so wird weiterhin das packages-Verzeichnis gelöscht. Grund ist das espeak-Paket (nutzt denn jemand dieses?). Bei diesem werden die Dateien in packages-Verzeichnis je nach gewählter Option überschrieben! D.h. es reicht nicht die überflüssigen Dateien von vorigen Builds zu löschen, es müssen auch die richtigen drüber kopiert werden. Das bei fast 20 sich in verschiedenen Verzeichnissen befindenden Dateien explizit zu machen, ist mir zu aufwendig, da definiere ich lieber die Option als SUBOPT und lösche das packages-Verzeichnis. Da wo es sich ohne großen Aufwand implementieren lässt, wird es schon so gemacht, dass die überflüssigen gelöscht werden ohne neu zu übersetzen.

Ich wollte zusätzlich noch fragen, ob alle mit meinen Makefiles auf Anhieb was anfangen können oder habe ich es eventuell mittlerweile zu weit getrieben. So würde z.B. das neue dosfstools-Makefile ausschauen:

$(call PKG_INIT_BIN, 3.0.5)
$(PKG)_SOURCE:=$(pkg)-$($(PKG)_VERSION).tar.gz
$(PKG)_SOURCE_MD5:=d48177cde9c6ce64333133424bf32912
$(PKG)_SITE:=http://www.daniel-baumann.ch/software/dosfstools

$(PKG)_BINARIES_ALL := dosfsck dosfslabel mkdosfs
$(PKG)_BINARIES := $(strip $(foreach binary,$($(PKG)_BINARIES_ALL),$(if $(FREETZ_PACKAGE_$(PKG)_$(shell echo $(binary) | tr [a-z] [A-Z])),$(binary))))
$(PKG)_BINARIES_BUILD_DIR := $($(PKG)_BINARIES:%=$($(PKG)_DIR)/%)
$(PKG)_BINARIES_TARGET_DIR := $($(PKG)_BINARIES:%=$($(PKG)_DEST_DIR)/usr/sbin/%)
$(PKG)_NOT_INCLUDED := $(patsubst %,$($(PKG)_DEST_DIR)/usr/sbin/%,$(filter-out $($(PKG)_BINARIES),$($(PKG)_BINARIES_ALL)))

# always compile with LFS enabled
$(PKG)_CFLAGS := $(subst $(CFLAGS_LARGEFILE),,$(TARGET_CFLAGS)) $(CFLAGS_LFS_ENABLED) -fomit-frame-pointer

$(PKG_SOURCE_DOWNLOAD)
$(PKG_UNPACKED)
$(PKG_CONFIGURED_NOP)

$($(PKG)_BINARIES_BUILD_DIR): $($(PKG)_DIR)/.configured
	PATH="$(TARGET_PATH)" \
		$(MAKE) -C $(DOSFSTOOLS_DIR) \
		CC="$(TARGET_CC)" \
		CFLAGS="$(DOSFSTOOLS_CFLAGS)" \
		all

$($(PKG)_BINARIES_TARGET_DIR): $($(PKG)_DEST_DIR)/usr/sbin/%: $($(PKG)_DIR)/%
	$(INSTALL_BINARY_STRIP)

$(pkg):

$(pkg)-precompiled: $($(PKG)_BINARIES_TARGET_DIR)

$(pkg)-clean:
	-$(MAKE) -C $(DOSFSTOOLS_DIR) clean

$(pkg)-uninstall:
	$(RM) $(DOSFSTOOLS_BINARIES_ALL:%=$(DOSFSTOOLS_DEST_DIR)/usr/sbin/%)

$(PKG_FINISH)

 

[olistudent]

Um ehrlich zu sein blick ich das nicht auf Anhieb. Vielleicht könntest du das im Trac (vielleicht an einem Beispiel) dokumentieren?

MfG Oliver

 

[Silent-Tears]

Um ne Doku dazu hatte ich dich ja schon mal per PN gebeten

 

[er13]

ich schreibe definitiv was dazu, versprochen, bloß erst nächste Woche, da ich übers Wochenende Besuch habe

 

[er13]

So habe eine neue Seite im Wiki angelegt, gefällt mir zwar noch nicht ganz, ist aber besser als nichts (ist auch meine erste Wiki-Seite, von daher nicht schimpfen, einfach verbessern ;-)).

Kann mir jemand vielleicht sagen, was ich tun muss, damit der neue Artikel im Inhaltsverzeichnis an der richtigen Stelle (an der letzten) erscheint?

 

[olistudent]

Ich hab keine Ahnung...

A wildcard '*' can be used to fetch a sorted list of all pages starting with the preceding pagename stub.

Nach was hat der sortiert???

MfG Oliver

 

[MaxMuster]

... gefällt mir zwar noch nicht ganz, ist aber besser als nichts

Ich finde sie super, alle relevanten Dinge sind drin:
- das "Grundprinzip und Problem"
- das Prinzip hinter dem neuen Ansatz
- nicht nur kurz angedeutet sondern auch noch die genutzen "Specials" kurz(!) erklärt, ohne ausschweifend zu werden

Besten Dank!

Jörg

 

[olistudent]

@er13
Die Seite wird jetzt nach dem Seitennamen sortiert. Du müsstest die Seite also umbennen, wenn dir die Position nicht gefällt.

MfG Oliver

 

[cuma]

Mir ist aufgefallen, dass die Upload-Werte circa nur halb so groß sind wie die der monatlichen AVM-eMails. Der Download passt. Was sind euere Erfahrungen?