Gecachte Dateien des Make-Prozesses

[dbler]

Hallo.

Ich habe eine eher allgemeine Frage zum Ertsellungsprozess.
Ich habe eine Regel zum Erstellen von htop erzeugt:

Code: Alles auswählen

#htop
$(DEPDIR)/htop: bootstrap libncurses @DEPENDS_htop@
	@PREPARE_htop@
	cd @DIR_htop@ && \
		$(BUILDENV) \
		[ ! -f $(targetprefix)/include/curses.h ] && \
			ln -s $(targetprefix)/include/ncurses/curses.h \
				$(targetprefix)/include/curses.h ; \
		./configure \
			--libdir=$(buildprefix)/@DIR_htop@ \
			--enable-shared \
			--build=$(build) \
			--host=$(target) \
			--prefix=$(targetprefix) \
			ac_cv_file__proc_stat=yes \
			ac_cv_func_malloc_0_nonnull=yes \
			ac_cv_func_realloc_0_nonnull=yes \
			ac_cv_file__proc_meminfo=yes && \
		$(MAKE) all && \
		@INSTALL_htop@
	@CLEANUP_htop@
	touch $@

htop wird damit auch fehlerfrei erstellt und läuft auf der Box
...allerding mit 20% Prozessorlast., aber das ist wohl kein Wunder.

Nach dem erfolgreichen Make wird das htop-Verzeichnis im CDK komplett gelöscht.
Bei einem weiteren Make werden scheinbar die Parameter aus dem configure nicht immer übernommen.

Meine Frage ist jetzt: Worauf bezieht sich Make bei weiteren Durchläufen, wenn nach dem erfolgreichem Durchlauf alle Objekte zum Paket gelöscht werden?
Was muss ich tun um auch die gecachten Werte des configure zu löschen?

[dbt]

Meinst du das? ...es läuft ohne was zu machen durch?

Code: Alles auswählen

   touch $@

Falls ja, lass das mal weg! musst aber in deps das .htop erst löschen

[rhabarber1848]

oder

Code: Alles auswählen

rm .deps/htop && make htop

[dbler]

Meinst du das? ...es läuft ohne was zu machen durch?

Code: Alles auswählen

   touch $@

Falls ja, lass das mal weg! musst aber in deps das .htop erst löschen

OK, also wird nicht gegen die Objekte der letzten Compilierung geprüft, sondern nur ob das Paket generell fehlerfrei erzeugt wurde (also bis zum touch $@ durchlief)?

Ich hatte nur beim testen der Vorgaben für configure ac_cv_XXX den Eindruck das sie nicht angenommen wurden und mit den vorherigen (vielleicht gecachten Werten?) compiliert wurden.
Könnte das sein?

[dbler]

oder

Code: Alles auswählen

rm .deps/htop && make htop

Die Reaktionen sind ja hier schneller als Licht
Danke.

[rhabarber1848]

OK, also wird nicht gegen die Objekte der letzten Compilierung geprüft, sondern nur ob das Paket generell fehlerfrei erzeugt wurde (also bis zum touch $@ durchlief)?

Ja.

Ich hatte nur beim testen der Vorgaben für configure ac_cv_XXX den Eindruck das sie nicht angenommen wurden und mit den vorherigen (vielleicht gecachten Werten?) compiliert wurden.
Könnte das sein?

Nein, da das Verzeichnis cdk/htop*/ nach dem Kompilieren komplett gelöscht wird.
Jeder compile-Vorgang fängt also von vorne an.

Du kannst das Kompilieren nach dem configure-Durchlauf abbrechen und Dir dann
config.log etc. anschauen und prüfen, ob Deine Änderungen angenommen wurden.

[dbler]

Alles klar, dann habe auch ich das jetzt verstanden

[rhabarber1848]

Wenn alles funktioniert, kann Dein htop-Patch gerne ins CVS.

[dbler]

Wenn alles funktioniert, kann Dein htop-Patch gerne ins CVS.

Soweit sieht jetzt alles gut aus, das Make läuft durch, erstellt das Programm im korrekten Verzeichnis und die Auführung auf der Box ist auch in Ordnung.
Wie wäre denn der üblich Weg das ins CVS zu bringen?

[rhabarber1848]

Wie wäre denn der üblich Weg das ins CVS zu bringen?

Poste einen Patch Deiner Änderungen am CVS-Sourcecode, dieser wird
dann getestet und, wenn für gut befunden, committed.

[dbler]

Der diff-Durchlauf cvs -z3 -d anoncvs@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox diff hat folgendes ergeben:

Code: Alles auswählen

Index: configure.ac
===================================================================
RCS file: /cvs/tuxbox/cdk/configure.ac,v
retrieving revision 1.277
diff -r1.277 configure.ac
1402a1403,1404
> TUXBOX_RULES_MAKE(htop)
Index: rules-archive
===================================================================
RCS file: /cvs/tuxbox/cdk/rules-archive,v
retrieving revision 1.492
diff -r1.492 rules-archive
131a132,133
> htop-0.9.tar.gz;http://downloads.sourceforge.net/project/htop/htop/0.9/
Index: rules-install
===================================================================
RCS file: /cvs/tuxbox/cdk/rules-install,v
retrieving revision 1.190
diff -r1.190 rules-install
122a123,124
> htop;make:install:DESTDIR=TARGET
Index: rules-make
===================================================================
RCS file: /cvs/tuxbox/cdk/rules-make,v
retrieving revision 1.533
diff -r1.533 rules-make
126a127,128
> htop;0.9;htop-0.9;htop-0.9.tar.gz;extract:htop-0.9.tar.gz
Index: make/contrib-apps.mk
===================================================================
RCS file: /cvs/tuxbox/cdk/make/contrib-apps.mk,v
retrieving revision 1.35
diff -r1.35 contrib-apps.mk
6c6
< contrib_apps: bzip2 console_data kbd fbset lirc lsof dropbear ssh tcpdump bonnie @LUFS@ kermit wget ncftp screen lzma lzma_host ntpd ntpclient links links_g esound python ser2net ipkg openvpn
---
> contrib_apps: bzip2 console_data kbd fbset lirc lsof dropbear ssh tcpdump bonnie @LUFS@ kermit wget ncftp screen lzma lzma_host ntpd ntpclient links links_g esound python ser2net ipkg openvpn htop
8c8
< CONTRIB_DEPSCLEANUP = rm -f .deps/bzip2 .deps/console_data .deps/kbd .deps/directfb_examples .deps/fbset .deps/lirc .deps/lsof .deps/ssh .deps/tcpdump .deps/bonnie .deps/vdr .deps/lufs .deps/dropbear .deps/kermit .deps/wget .deps/ncftp .deps/screen .deps/lzma .deps/lzma_host .deps/ntpd .deps/ntpclient .deps/links .deps/links_g .deps/esound .deps/openntpd .deps/python .deps/ser2net .deps/ipkg .deps/openvpn
---
> CONTRIB_DEPSCLEANUP = rm -f .deps/bzip2 .deps/console_data .deps/kbd .deps/directfb_examples .deps/fbset .deps/lirc .deps/lsof .deps/ssh .deps/tcpdump .deps/bonnie .deps/vdr .deps/lufs .deps/dropbear .deps/kermit .deps/wget .deps/ncftp .deps/screen .deps/lzma .deps/lzma_host .deps/ntpd .deps/ntpclient .deps/links .deps/links_g .deps/esound .deps/openntpd .deps/python .deps/ser2net .deps/ipkg .deps/openvpn .deps/htop
707a708,740
> 
> #htop
> $(DEPDIR)/htop: bootstrap libncurses @DEPENDS_htop@
> 	@PREPARE_htop@
> 	cd @DIR_htop@ && \
> 		$(BUILDENV) \
> 		[ ! -f $(targetprefix)/include/curses.h ] && \
> 			ln -s $(targetprefix)/include/ncurses/curses.h \
> 				$(targetprefix)/include/curses.h ; \
> 		./configure \
> 			--build=$(build) \
> 			--host=$(target) \
> 			--prefix= \
> 			ac_cv_file__proc_stat=yes \
> 			ac_cv_file__proc_meminfo=yes \
> 			ac_cv_func_malloc_0_nonnull=yes \
> 			ac_cv_func_realloc_0_nonnull=yes && \
> 		$(MAKE) all && \
> 		@INSTALL_htop@
> 	@CLEANUP_htop@
> 	touch $@
> 

Hab noch nicht wirklich mit dem CVS gearbeitet
Geht das so in Ordnung?

[dbt]

Im Prinzip ja, unified Format sieht aber besser aus.
Das was da rauskommt am besten in eine Datei packen und hochladen. Die Abbildung im Browser und Übernahme mittels CopyPaste ist mit Diffs ist meistens etwas anstrengend wegen der Formatierung der Tabs und Umbrüche hat man wahrscheinlich immer Probleme, den Patch anzuwenden. Im Dateinamen den Stand hinterlegen, damit man die Revision nachvollziehen kann. Etwa so:

Code: Alles auswählen

cvs-diff_[das_macht_der_Patch]_2011-01-26-08-01-39.diff

[dbler]

So, ich habe das jetzt als unified diff angehängt...
Das mit dem Copy&Paste sehe ich ein, war ja auch nur der erste Versuch

[rhabarber1848]

committed mit einigen Extras:
http://article.gmane.org/gmane.comp.vid ... x.scm/2634
http://article.gmane.org/gmane.comp.vid ... x.scm/2635

zusätzliches make target: flash-htop
configure-Option: --enable-htop

Im Flash-Image belegt htop hier 114504 byte, libncurses.so.5 wächst durch
die von htop benötigten Funktionen hier von 43652 auf 159940 byte.

[rhabarber1848]

...allerding mit 20% Prozessorlast., aber das ist wohl kein Wunder.

Im yadd-none hat htop für sich 10% angezeigt.

[dbler]

...allerding mit 20% Prozessorlast., aber das ist wohl kein Wunder.

Im yadd-none hat htop für sich 10% angezeigt.

Also ich hab's gerade nochmal getestet: bin meistens über 15%. Aber das ist ja auch nicht so das Problem.

committed mit einigen Extras:

Schön das ich einen kleinen Beitrag leisten konnte