"--with-boxtype" überarbeiten

[seife]

Guten Morgen.

boxtype-rework.diff

Das ist mein Versuch, "--with-boxtype=..." zu überarbeiten.
Bisher wurde das in unzähligen configure.ac's gemacht, ich habe es jetzt in acinclude.m4 verlegt, als "TUXBOX_BOXTYPE" macro.
Dummerweise gibt es drei verschiedene acinclude.m4, eines in apps/, eines in apps/tuxbox/plugins und eins in apps/tuxbox/enigma. Meine autofoo-Künste sind nicht so, dass ich die hätte vereinen wollen, also habe ich alle 3 gepatched. Jedenfalls sind es jetzt nur noch 3 Stellen anstatt 8 configure.ac's

Des weiteren habe ich die HAVE_{DREAMBOX,DBOX,TRIPLEDRAGON} defines alle mal in config.h gemacht, das über die CFLAGS zu übergeben finde ich persönlich suboptimal.

Ausserdem gibt es noch einen neuen boxtype "generic", da könnte man alles das, was ohne spezielle Hardware geht, also z.B. auf einem PC mit DVB-Karte mit rein-#definen. Ob das übertrieben nützlich ist, weiss ich noch nicht, aber es war praktisch umsonst mit zu haben.

Ich lasse gerade 2 Testcompiles laufen, eines für dbox und eines für dream, damit ich sehe ob es in einem ansonsten sauberen CVS auch funktioniert.

Ansonsten wäre es interessant, wenn da mal einer der automake-Spezis draufschaug (rhabarber1848?) und ob es hinterher auch noch funktioniert (im dümmsten Fall ist ein HAVE_DBOX_HARDWARE oder HAVE_DREAMBOX_HARDWARE falsch gesetzt und alles kompiliert zwar lustig, aber passt hinterher nicht zur box). Ich werde das morgen oder am Wochenende auch mal selbst probieren, aber bin an Feedback natürlich interessiert.

[Barf]

seife, ich finde es toll, dass du dich über diese Thema kümmerst.

Zwei schnelle Bemerkungen:

Wäre es nicht möglich, anstatt den standard configure-Option --build (in Standardform cpu-company-system) zu benutzen?
Siehe http://www.gnu.org/prep/standards/html_ ... figuration. Ich glaube, die auto*-Tools decken diese Situation (am mindestens in Wesentliches) ab, und dann wäre es "suboptimal" neue Optionen zu erfinden.

Zweitens zum Gebrauch von Präprozessorsymbolen: Es ist kein gute Programmierung, Code der z.B. spezifische Hardware voraussetzt mit Symbolen wie HAVE_DREAMBOX_HARDWARE zu ifdef-en. Es ist dem Leser des Codes u.U. unklar, welche Eigenschaft des (heutigen?, zukünftige?) Dreambox zu diese Einscheidung geführt hat, und falls die Entscheidung noch gültigkeit hat. Besser wäre Eigenschaftsbasierte Präprozessorsymbole, wie HAVE_SAA7126. Das X-Window system enthält Beispiele.

http://www.gnu.org/prep/standards/html_ ... ompilation ist auch lesenswert...

[seife]

Das Problem ist, dass bisher halt schon "--with-boxtype" verwendet wurde. Das ist unter anderem auch im dreambox-branch so, welcher aber wieder enigma aus HEAD verwendet. Um da nicht zuviel kaputt zu machen oder alles anfassen zu müssen, wollte ich beim "--with-boxtype" bleiben.

Mit den #defines hast du natürlich recht, aber es ist halt wieder so, dass es bisher mit "#ifdef HAVE_DREAMBOX_HARDWARE" und "#ifndef HAVE_DREAMBOX_HARDWARE" gemacht wurde.
Generell sind die "#ifndef HAVE_*_HARDWARE" IMHO immer kritisch. Anfangs war HAVE_DREAMBOX_HARDWARE dasselbe wie !HAVE_DBOX_HARDWARE, deswegen war ein HAVE_DBOX_HARDWARE gar nicht notwendig oder vorhanden, aber wenn ich noch TRIPLEDRAGON und GENERIC dazu mache, dann wird es schwieriger.

Du bist herzlich eingeladen, das später auf einzelne Chips aufzubröseln (die #defines könnte man jetzt schon hinzufügen), momentan geht es mir erst mal drum, dass es überhaupt noch funktioniert und ich wäre für Tests dankbar.

(Und z.B. die DM7000 und die Tripledragon haben ziemlich ähnliche Hardware, aber sind halt von der API komplett verschieden, schau mal in meinem dm500.git in den "tripledragon" branch, dann siehst du, was ich meine )

[seife]

Keine Beschwerden? Kann also eingecheckt werden?

[rhabarber1848]

Ich habe damit einige yadd-neutrinos gebaut und keine
Probleme auf der Dbox2 feststellen können, also ab ins CVS.

[seife]

Hast recht, ich habe es mal committed.
Ich befürchte, dass es auf der dreambox nebenwirkungen geben könnte, deswegen probiere ich es dort gerade noch aus (zumindest bei enigma werden nur Teile von apps/ auf den HEAD-Stand updated, insofern muss ich evtl. noch Anpassungen im dreambox-Branch vornehmen), aber das sollten keine unlösbaren Probleme sein.

[Houdini]

da fehlt wohl noch was:

Code: Alles auswählen

Generating configuration files for tuxbox-zapit, please wait....
  aclocal
  libtoolize --automake
  autoconf
  autoheader
  automake --add-missing
src/zapost/Makefile.am:7: BOXTYPE_DREAMBOX does not appear in AM_CONDITIONAL
make: *** [/home/harald/tuxbox-cvs/head-new/apps/dvb/zapit/config.status] Fehler 1

[seife]

Ist das mit einem neuen checkout? Oder anders gesagt: was sagt "ls -l acinclude.m4" in deinem apps/dvb/zapit-Ordner? Bei mir sieht das so aus:

Code: Alles auswählen

seife@stoetzler:/local/seife/src/tuxbox-devel/apps/dvb/zapit> l acinclude.m4
lrwxrwxrwx 1 seife suse 63  5. Okt 19:28 acinclude.m4 -> /local/seife/src/tuxbox-devel/apps/dvb/zapit/../../acinclude.m4

Das apps/acinclude.m4 muss gepatched worden sein, also "AC_DEFUN([TUXBOX_BOXTYPE],[" enthalten.
Im configure.ac von zapit muss "TUXBOX_BOXTYPE" drin stehen.

Ich will nicht ausschliessen, dass was an meinem Commit falsch ist (autoconf ist nicht meine Stärke), aber es hat bei mir bei vielen Testläufen funktioniert und bei rhabarber1848 auch, deswegen wundert es mich ein wenig.

[Houdini]

Code: Alles auswählen

harald@houdini:~/tuxbox-cvs/head-new/apps/dvb/zapit$ ls -la acinclude.m4
lrwxrwxrwx 1 harald harald 66  8. Jan 21:48 acinclude.m4 -> /home/harald/tuxbox-cvs/head-new/apps/dvb/zapit/../../acinclude.m4

habe ich auch

aber apps/acinclude.m4 war nicht aktuell...
die hat mir mein crossvc irgendwie vorenthalten
Jetzt geht wieder, Danke!

[rhabarber1848]

FYI: Bin gerade über diverse "#ifdef DBOX" in Neutrino gestolpert,
vielleicht willst Du da auch noch ran.

[seife]

Sollten jetzt ein paar weniger sein, aber noch nicht alle.
(Ich suche die nicht gezielt, ich fixe nur die, die mir beim portieren auf die TD auffallen )

[GetAway]

Habe jetzt neu ausgecheckt.

Hier bricht es ab.

Code: Alles auswählen

setting_helpers.cpp:311: error: `CSPTSNotifier' has not been declared
../../src/gui/widget/menue.h:61: warning: unused parameter 'OptionName'
../../src/gui/widget/menue.h:61: warning: unused parameter 'Data'
setting_helpers.cpp:809: warning: unused parameter 'actionKey'
setting_helpers.cpp:604: warning: unused parameter 'parent'
setting_helpers.cpp:604: warning: unused parameter 'actionKey'
setting_helpers.cpp:580: warning: unused parameter 'parent'
setting_helpers.cpp:580: warning: unused parameter 'actionKey'
setting_helpers.cpp:524: warning: unused parameter 'parent'
make[4]: *** [setting_helpers.o] Fehler 1
make[4]: Verlasse Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4/apps/tuxbox/neutrino/src/system'
make[3]: *** [all-recursive] Fehler 1
make[2]: *** [all-recursive] Fehler 1
make[1]: *** [all] Fehler 2
make: *** [/home/getaway/tuxbox/dbox2-2.4/cdkflash/root-neutrino] Fehler 2
make[3]: Verlasse Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4/apps/tuxbox/neutrino/src'
make[2]: Verlasse Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4/apps/tuxbox/neutrino'
make[1]: Verlasse Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4/apps/tuxbox/neutrino'
Ready .... press Enter

//--Edit:
Fehlt das:

Code: Alles auswählen

#include <config.h>

[Striper]

Bekomme den gleichen Fehler.

/edit

@GetAway
Der include isses nicht. Hab ich versucht.

Fehlt da noch irgendwo ein TUXBOX_BOXTYPE?

[rhabarber1848]

Fehlt das:

Code: Alles auswählen

#include <config.h>

Ja, fixed in CVS: http://cvs.tuxbox-cvs.sourceforge.net/c ... 90&r2=1.91

[Striper]

*bonk*

Hatt es in setting_helpers.cpp drin ^^
Danke rhabarber1848!

[seife]

Danke. Ich hatte das schon gefixt, aber beim Export ins CVS ist das verloren gegangen...

[gugu]

Wie kann ich das für dreambox anwenden ?
Ich kann "--with-boxtype" in configure nicht finden.

[seife]

wenn du "./prepare dm500" machst, wird automatisch --with-boxtype=dm500 benutzt. Ausserdem wird im dreamboxbranch fest "-DHAVE_DREAMBOX_HARDWARE" in die CFLAGS geknallt.

[gugu]

Ich möchte das Head teil testen, oder wozu hast du das eingebaut ?

[seife]

du kannst ja mal versuchen, "make checkout_neutrino" anstelle von "make checkout" zu machen, dann wird komplett apps/ auf HEAD updated, damit müsstet du auch enigma bauen können. Mit dem cdk/-Verzeichnis aus HEAD kannst du kein dreamboximage bauen.
Eingebaut habe ich das, weil apps/ auch ausserhalb vom tuxbox-CDK verwendet werden können. Meine Änderungen sind auch nur unterhalb von apps/

Natürlich könnte man das gesamte CDK so umbauen, dass man beim configure "--with-boxtype" angeben und dann automatisch das entsprechende Image bauen würde, aber ich werde das nicht tun.

[gugu]

Natürlich könnte man das gesamte CDK so umbauen, dass man beim configure "--with-boxtype" angeben und dann automatisch das entsprechende Image bauen würde, aber ich werde das nicht tun.

Was fehlt in CDK um "--with-boxtype" binarys zu bauen ?
Ich will nur neutrino nicht ganze Image bauen.

[seife]

Alles. Die dreambox verwendet andere versionen von glibc und compiler (mit anderen patches und anderen Maschinen-/Architekturoptionen), sie hat andere Treibersourcen, ...

Das könnte man alles einbauen, aber das musst du schon selber machen. Das "--with-boxtype" ist dabei das kleinste Problem.

[dwilx]

Alles. Die dreambox verwendet andere versionen von glibc und compiler (mit anderen patches und anderen Maschinen-/Architekturoptionen), sie hat andere Treibersourcen, ...

Das könnte man alles einbauen, aber das musst du schon selber machen. Das "--with-boxtype" ist dabei das kleinste Problem.

Das wäre eine schöne Aufgabe, der sich jemand annehmen könnte, dann kann man sich den Dreamboxbranch endlich sparen. "duck". Und so wie ich es dem hier entnommen habe, sollte das auch längerfristig gemacht werden. So sieht mir das etwas zu "provisorisch" aus, aber wer solls denn machen? Ist sicher ein Haufen Arbeit, da sich der Dreamboxbranch wohl auf Oldmake aufbaut. Mir kommt es nur so vor, als würde das sogar für Spezies nicht so einfach sein, sich da reinzuwuseln.

[gugu]

Das "--with-boxtype" ist dabei das kleinste Problem.

Kannst du mir Lösung für das kleinste Problem verraten ?

[seife]

Vor allem reitet man ja wirklich mehrere tote Pferde:
- es gibt kaum noch dreamboxen, die aus dem tuxbox-CDK "bedient" werden. Die Dreambox-Jungs sind weitergezogen zu OpenEmbedded (und das nicht ohne Grund).
- die verbliebene Dreambox-Kundschaft ist eher "konservativ". Die werden also auch weiter ihren dreambox-Branch benutzen.

Tatsächlich sieht es für mich eher so aus, dass ich meine dboxen auch per openembedded betanke (oder mir einfach Crosscompiler-Pakete für meine bevorzugte Distribution bauem bzw. das Kompilieren nativ im QEMU machen werde), weil die Insellösung tuxbox-CDK, so gut sie auch funktionieren mag, trotz allem relativ beschränkt ist.

Ausserdem werde ich irgendwie das Gefühl nicht los dass die, die das erweitern von newmake um andere Boxtypen etc. für eine gute Idee halten, noch nie für was anderes als die dbox gebaut haben.

Executive summary: ich werde keine Arbeit reinstecken, damit ich ein Problem löse, dass andernorts schon mehrfach gelöst wurde.

Das "--with-boxtype" ist dabei das kleinste Problem.

Kannst du mir Lösung für das kleinste Problem verraten ?

Da ist kein Problem. Das Makefile im dreambox-branch übergibt schon --with-boxtype=... an alle beteiligten configure-Skripten.
Ebenso kannst du auch im newmake an das configure von neutrino "--with-boxtype..." anhängen. Aber das neutrino wird dann
a) Nicht bauen
b) selbst wenn es bauen würde würde es so auf der dreambox vermutlich nicht laufen.

Erzähl doch mal (in einem eigenen Thread, weil hier ist das ziemlich sicher offtopic) was du machen willst, dan kann dir evtl. auch geholfen werden.