Anfängerfrage, Dbox2/Linux-Entwicklung und Tipps

[mschmidt]

Hallo!

Ich arbeite normalerweise mit Visual Studio unter Windows (hoffentlich "schlägt" mich jetzt keiner), und habe deshalb kaum Ahnung und Erfahrung mit Software-Entwicklung unter Linux, geschweige denn in einer Cross-Compiler-Umgebung oder mit den unter Linux üblicherweise genutzten Build-Systemen (autogen/configure/etc).

Ich habe es zwar (dank "newmake"?) problemlos geschafft, das CVS zu kompilieren und ein "yadd" in Betrieb zu nehmen, allerdings habe ich ein paar Fragen und Probleme und es wäre nett, wenn mir dabei Jemand etwas "unter die Arme" greifen könnte:

- Warum wird (bei mir?) bei einer reinen Source-Code-Änderung von z.B. "apps/dvb/zapit/src/udpstreampes.cpp" und anschließendem "make" des kompletten CVS das executable nicht neu erstellt? Erst nach einem "clean" und rebuild wird das executable erstellt. Wird von dem Buildsystem/"make" nicht erkannt, daß sich eine Quelle geändert hat (...und alle davon abhängigen automatisch neu erstellt) - ich denke, dafür hat man ein "make"??

- Warum finde ich das executable im o.g. Beispiel unter dem "apps/dvb/zapit/src/.libs"-Verzeichnis und dort, wo ich eigentlich das executable erwarten würde "apps/dvb/zapit/src/", liegt ein Bash-Script, daß scheinbar vom Build-System erzeugt wurde. Was hat es damit auf sich und wofür ist das gut?

- Gibt es eine Möglichkeit, bzw. wie kann ich, ein einzelnes Tool aus dem CVS übersetzen lassen, z.B. "udpstreampes.cpp", ohne das komplette CVS übersetzen zu müssen? Gibt es dafür ein Script, was mir die entsprechende Umgebung für den Compiler einrichtet, etc??? Wie rufe ich den Compiler "von Hand" auf? Wie arbeitet Ihr bei solchen Änderungen?

- Gibt es für eine vernünftige Entwicklungs-Umgebung unter Linux mit der man Software für die Dbox2 "cross"-entwickeln kann, für mich idealerweise natürlich ähnlich wie VS? Mit was arbeitet Ihr bzw. was benutzt man dafür? Hardcore via Text-Editor und Shell kann ich mir irgendwie fast nicht vorstellen.

Vielen Dank!!

cu/MSchmidt

[Houdini]

- Warum wird (bei mir?) bei einer reinen Source-Code-Änderung von z.B. "apps/dvb/zapit/src/udpstreampes.cpp" und anschließendem "make" des kompletten CVS das executable nicht neu erstellt? Erst nach einem "clean" und rebuild wird das executable erstellt. Wird von dem Buildsystem/"make" nicht erkannt, daß sich eine Quelle geändert hat (...und alle davon abhängigen automatisch neu erstellt) - ich denke, dafür hat man ein "make"??

Tja, diese warum Fragen, das Buildsystem ist hier zweistufig, auf oberster Ebene gibt es die "markerfiles" in cdk/.deps.
Wenn diese existieren, werden die Abhängigkeiten in den Sourcen nicht mehr geprüft.
Um also zapit neu zu erstellen mache ich immer

Code: Alles auswählen

rm .deps/zapit
make .deps/zapit

- Warum finde ich das executable im o.g. Beispiel unter dem "apps/dvb/zapit/src/.libs"-Verzeichnis und dort, wo ich eigentlich das executable erwarten würde "apps/dvb/zapit/src/", liegt ein Bash-Script, daß scheinbar vom Build-System erzeugt wurde. Was hat es damit auf sich und wofür ist das gut?

Die meisten der executable/libs aus dem apps Zweig werden in den .libs directories erstellt, warum kann ich dir auch nicht sagen, aber sie werden dann auch ins cdkroot/bin oder lib Verzeichnis kopiert.

- Gibt es eine Möglichkeit, bzw. wie kann ich, ein einzelnes Tool aus dem CVS übersetzen lassen, z.B. "udpstreampes.cpp", ohne das komplette CVS übersetzen zu müssen? Gibt es dafür ein Script, was mir die entsprechende Umgebung für den Compiler einrichtet, etc??? Wie rufe ich den Compiler "von Hand" auf? Wie arbeitet Ihr bei solchen Änderungen?

Das geht fast mit jedem standard powerpc cross compiler, die libs/headers müssen dazu natürlich existieren.
also z.B.: $Crosscompilerpath/bin/powerpc-linux-$foo-gcc tool.c -o tool
Da du aber schon das cvs generiert hast würde ich da ansetzen und wie oben einfach das entsprechende markerfiel löschen.

- Gibt es für eine vernünftige Entwicklungs-Umgebung unter Linux mit der man Software für die Dbox2 "cross"-entwickeln kann, für mich idealerweise natürlich ähnlich wie VS? Mit was arbeitet Ihr bzw. was benutzt man dafür? Hardcore via Text-Editor und Shell kann ich mir irgendwie fast nicht vorstellen.

jup, genau so. Ich nutze kdevelop und ne shell

[StevenSch]

"Eclipse" geht auch. Ist eine ziemlich mächtige Open Source Programmier-Suite inkl. CVS-Funktion. Das Programm gibts für Linux / Windows / Mac da es in Java geschrieben ist.

[Barf]

- Warum wird (bei mir?) bei einer reinen Source-Code-Änderung von z.B. "apps/dvb/zapit/src/udpstreampes.cpp" und anschließendem "make" des kompletten CVS das executable nicht neu erstellt? Erst nach einem "clean" und rebuild wird das executable erstellt. Wird von dem Buildsystem/"make" nicht erkannt, daß sich eine Quelle geändert hat (...und alle davon abhängigen automatisch neu erstellt) - ich denke, dafür hat man ein "make"??

Es sollte funktionieren wie du erwartest -- am mindestens in Großen und Ganzen, sonst ist es ein Bug.

Ganz daneben ist aber:

Zitat:
- Warum wird (bei mir?) bei einer reinen Source-Code-Änderung von z.B. "apps/dvb/zapit/src/udpstreampes.cpp" und anschließendem "make" des kompletten CVS das executable nicht neu erstellt? Erst nach einem "clean" und rebuild wird das executable erstellt. Wird von dem Buildsystem/"make" nicht erkannt, daß sich eine Quelle geändert hat (...und alle davon abhängigen automatisch neu erstellt) - ich denke, dafür hat man ein "make"??

Tja, diese warum Fragen, das Buildsystem ist hier zweistufig, auf oberster Ebene gibt es die "markerfiles" in cdk/.deps.
Wenn diese existieren, werden die Abhängigkeiten in den Sourcen nicht mehr geprüft.
Um also zapit neu zu erstellen mache ich immer
Code:
rm .deps/zapit
make .deps/zapit

Dieser Gräuel wurde mit newmake eliminiert.

- Warum finde ich das executable im o.g. Beispiel unter dem "apps/dvb/zapit/src/.libs"-Verzeichnis und dort, wo ich eigentlich das executable erwarten würde "apps/dvb/zapit/src/", liegt ein Bash-Script, daß scheinbar vom Build-System erzeugt wurde. Was hat es damit auf sich und wofür ist das gut?

Das libtool ist dafür verantworlich: Es wird versucht, das Programm auch am Buildort ausführbar zu machen. Siehe die libtooldokumentation, falls es dich intressiert.

- Gibt es eine Möglichkeit, bzw. wie kann ich, ein einzelnes Tool aus dem CVS übersetzen lassen, z.B. "udpstreampes.cpp", ohne das komplette CVS übersetzen zu müssen? Gibt es dafür ein Script, was mir die entsprechende Umgebung für den Compiler einrichtet, etc??? Wie rufe ich den Compiler "von Hand" auf? Wie arbeitet Ihr bei solchen Änderungen?

Oft gibt es ein entsprechende Maketarget (hier dvb_tools) das man von der Kommandozeile aufrufen kann, also

make dvb_tools

[Houdini]

Code: Alles auswählen

Ganz daneben ist aber:

Danke...

Du hast recht, für die apps/* Bereiche gilt das nicht mehr,
wohl aber für all die anderen externen Pakete.

[Barf]

...wohl aber für all die anderen externen Pakete.

Nein, es ist anderes. Die externe Pakete werden runtergeladen, ausgepackt, kompiliert, installiert. Danach wird der Buildbaum gelöscht. Sie hängen also von ihre Downloadfile (typischerweise *.tar.gz) und eventuell von einem Patchfile ab. Und, wonder of all wonders, die Makefile* kennt diese Abhängigkeiten (@DEPENDS_package). Deswegen, falls z.B. entsprechende Patchfile geändert wird, wird make ensprechende Target als veraltet betrachten, und bei Bedarf neubauen. Bedarf Markerfiles in .deps zu Löschen sollte der Vergangenheit gehören.

Falls es anderes funktioniert ist es ein Bug, zu Dokumentieren und Fixen.

[mschmidt]

- Warum wird (bei mir?) bei einer reinen Source-Code-Änderung von z.B. "apps/dvb/zapit/src/udpstreampes.cpp" und anschließendem "make" des kompletten CVS das executable nicht neu erstellt? Erst nach einem "clean" und rebuild wird das executable erstellt. Wird von dem Buildsystem/"make" nicht erkannt, daß sich eine Quelle geändert hat (...und alle davon abhängigen automatisch neu erstellt) - ich denke, dafür hat man ein "make"??

Es sollte funktionieren wie du erwartest -- am mindestens in Großen und Ganzen, sonst ist es ein Bug.

Nehmen wir mal an, es wäre ein Bug, gibt es eine Möglichkeit, z.B. nur ZAPIT zu cleanen und neu zu erstellen?

Um also zapit neu zu erstellen mache ich immer
Code:
rm .deps/zapit
make .deps/zapit

Dieser Gräuel wurde mit newmake eliminiert.

Ok, ich dachte schon, ich bin bescheuert, da ich das im Beispiel genannte .deps-file nicht auf meinem System gefunden habe.
Lediglich ".deps/*.Po" files, deren Löschen allerdings zu einen nicht-mehr funktionierenden Build geführt haben.

- Warum finde ich das executable im o.g. Beispiel unter dem "apps/dvb/zapit/src/.libs"-Verzeichnis und dort, wo ich eigentlich das executable erwarten würde "apps/dvb/zapit/src/", liegt ein Bash-Script, daß scheinbar vom Build-System erzeugt wurde. Was hat es damit auf sich und wofür ist das gut?

Das libtool ist dafür verantworlich: Es wird versucht, das Programm auch am Buildort ausführbar zu machen. Siehe die libtooldokumentation, falls es dich intressiert.

Jetzt verstehe ich auch die Erklärung im Header des Scripts, denke ich. Allerdings macht dieser Mechnismus doch bei einer Cross-Compile-Umgebung nicht viel Sinn, oder doch?
Wenn ich das richtig verstanden habe, könnte das ja wenn überhaupt nur dann funktionieren, wenn ich auf dem Zielsystem dieselbe Verzeichnisstruktur wie auf dem Host habe und versuche, die ausführbare Datei über das Script auf dem Zielsystem zu starten?

- Gibt es eine Möglichkeit, bzw. wie kann ich, ein einzelnes Tool aus dem CVS übersetzen lassen, z.B. "udpstreampes.cpp", ohne das komplette CVS übersetzen zu müssen? Gibt es dafür ein Script, was mir die entsprechende Umgebung für den Compiler einrichtet, etc??? Wie rufe ich den Compiler "von Hand" auf? Wie arbeitet Ihr bei solchen Änderungen?

Oft gibt es ein entsprechende Maketarget (hier dvb_tools) das man von der Kommandozeile aufrufen kann, also

make dvb_tools

Das funktioniert dann aber nur über die definierten Targets aus dem CDK-Verzeichnis oder geht das auch anders?
Der Versuch, ZAPIT z.B. durch ein "make" im Zapit-Verzeichnis zu erstellen, ist fehlgeschlagen, weil der Compiler nicht gefunden wurde. Ich denke, hier fehlen sämtliche Pfade, etc..!?

[Barf]

Nehmen wir mal an, es wäre ein Bug, gibt es eine Möglichkeit, z.B. nur ZAPIT zu cleanen und neu zu erstellen?

Angenommen dein rootpath ist /home/tuxbox/head, dann soll (von /home/tuxbox/head/cdk)

Code: Alles auswählen

make -C /home/tuxbox/head/apps/dvb/zapit distclean
make zapit

es tun.

Jetzt verstehe ich auch die Erklärung im Header des Scripts, denke ich. Allerdings macht dieser Mechnismus doch bei einer Cross-Compile-Umgebung nicht viel Sinn, oder doch?
Wenn ich das richtig verstanden habe, könnte das ja wenn überhaupt nur dann funktionieren, wenn ich auf dem Zielsystem dieselbe Verzeichnisstruktur wie auf dem Host habe und versuche, die ausführbare Datei über das Script auf dem Zielsystem zu starten?

Yup, der Wert dieses Feature falls der Targetprozessor != Hostprozessor ist "beschränkt".

Der Versuch, ZAPIT z.B. durch ein "make" im Zapit-Verzeichnis zu erstellen, ist fehlgeschlagen, weil der Compiler nicht gefunden wurde. Ich denke, hier fehlen sämtliche Pfade, etc..!?

Genau so ist es. Macht man aber "make zapit" vom cdk-Verzeichniss werden sie aber korrekt.

[mschmidt]

Barf, vielen Dank für die Erklärung - ich denke, da komme ich erstmal mit vernünftigen "Turn-around-Zeiten" zurecht.

Ich hätte jetzt allerdings noch zwei kleine Fragen:

- Unter http://wiki.tuxbox.org/wiki/index.php/Plugins:Tutorial findet sich ein "HOW-TO", wie man ein "Hello-World" als Plugin einbindet und übersetzt, sollte das auch mit NEWMAKE funktionieren? Der Autor schildert nämlich beim Build, daß ".deps/plugin" gelöscht werden soll, was es inzwischen ja nicht mehr gibt, deshalb vermute ich, daß die Beschreibung für OLDMAKE gedacht war/ist?

- Rein interesse halber: Kann man das Build-System auch so konfigurieren, daß es mehrere Kerne bzw. Multithreading nutzt? Gibt es dafür eine Option, mit "--help" habe ich leider nichts gefunden? Gerade ein Build-System müsste doch aufgrund korrekt beschriebener Abhängigkeiten ideal für die parallelisierung geeignet sein??

Danke!

[seife]

Teilweise. "make $YOURTARGET J=4" startet bis zu 4 Prozesse parallel, für die Teile, bei denen schon verifiziert wurde, dass es auch funktioniert.

Irgendwann mach ich das mal so, dass einfaches "make -j" auch funktioniert.

[Barf]

- Unter http://wiki.tuxbox-cvs.sourceforge.net/ ... s:Tutorial findet sich ein "HOW-TO", wie man ein "Hello-World" als Plugin einbindet und übersetzt, sollte das auch mit NEWMAKE funktionieren? Der Autor schildert nämlich beim Build, daß ".deps/plugin" gelöscht werden soll, was es inzwischen ja nicht mehr gibt, deshalb vermute ich, daß die Beschreibung für OLDMAKE gedacht war/ist?

Die wiki-Beschreibung hat einige Probleme (die YADI-Werbung ist einfach peinlich), trotzdem glaube ich (!= weiss ich) dass es in Großen und Ganzen stimmt.

Bzgl. paralleles Make hat seife schon beantwortet.

[dbt]

...um sonst ist dieser Text nicht dort hin gepinnt:

Dieser Artikel befindet sich derzeit im Reviewprozess. Hilf mit, ihn zu verbessern!

[mschmidt]

Barf, Seife und dbt:

Vielen Dank für die Tipps. Das die WIKI-Beschreibung nicht so ganz auf dem aktuellen Stand ist, habe ich auch schon gemerkt (z.B. kommt beim Link http://www.yadi.org nichts wirklich sinngemäßes)...

Sei es drum. Die Sache mit dem "Hello-World" Plug-in und dem parallelisieren werde ich versuchen und testen und bin so frech, Probleme die dabei auftreten zu melden.

Vielen Dank!

PS: Eins noch: auch wenn ich erstmal nach dem "udpstreampes" schauen wollte und dafür wohl keine weitergehende Doku und Beschreibung brauche, gibt es denn für die API (Zapit und Co) irgendeine Doku? Wenn ja, wo finde ich diese? Im CVS-Tree habe ich in der Richtung gar nichts gefunden.

[schattenmann]

Hallo zusammen,

bin neu hier. Nach jahrelanger Nutzung eines Analogreceivers bin ich nun seit ein paar Wochen am Recherchieren, welchen digitalen Receiver ich kaufen soll. Da hat sich sehr sehr viel getan und es ging an mir komplett vorbei. Daher melde ich mich in vielen Foren an, lesen mich ein usw. Neben den Hinweisen zu einzelnen Receivern stolpert man früher oder später über die Betriebssysteme, Plugins usw., die meistens von den Communities entwickelt werden. Da ich auch dieses Thema interessant finde, versuche ich mich auch darüber zu informieren (noch ganz am Anfang). Habe soweit den Link zum Development-Bereich in Wiki (noch nicht dazugekommen, es mir näher anzusehen), aber dieser Thread hier (auch wenn die letzte Antwort 2 jahre alt ist) lädt ein, hier zu posten, was hoffentlich ok ist.

Hallo!

Ich arbeite normalerweise mit Visual Studio unter Windows (hoffentlich "schlägt" mich jetzt keiner), und habe deshalb kaum Ahnung und Erfahrung mit Software-Entwicklung unter Linux, geschweige denn in einer Cross-Compiler-Umgebung oder mit den unter Linux üblicherweise genutzten Build-Systemen (autogen/configure/etc).

Das ist bei mir ziemlich ähnlich (bis auf Visual Studio). Daher sind auch die Fragen ähnlich, zumindest einige. mschmidt war zu dem Zeitpunkt wohl schon um einiges weiter.

Bei mir sind es erst eher ganz grundsätzliche Fragen.

1) Eine davon

[...]
- Gibt es für eine vernünftige Entwicklungs-Umgebung unter Linux mit der man Software für die Dbox2 "cross"-entwickeln kann, für mich idealerweise natürlich ähnlich wie VS? Mit was arbeitet Ihr bzw. was benutzt man dafür? Hardcore via Text-Editor und Shell kann ich mir irgendwie fast nicht vorstellen.
[...]

wurde beantwortet:

[...]
jup, genau so. Ich nutze kdevelop und ne shell

[...]
"Eclipse" geht auch. Ist eine ziemlich mächtige Open Source Programmier-Suite inkl. CVS-Funktion. Das Programm gibts für Linux / Windows / Mac da es in Java geschrieben ist.

Trifft das noch zu? Gibt es inzwischen Änderungen / andere (bessere) Umgebungen?

2) Grundsätzlich geht es hier um Entwicklung von Neutrino / NeutrinoHD, richtig?

3) C++ ist die Programmiersprache von Neutrino / NeutrinoHD, richtig?

4) Und jetzt nicht lachen: Beim "Ergebnis" handelt es nicht um eine exe-Datei, nehme ich mal an. Wie testet man das, was man programmiert? Muss man die Änderungen erst auf eine Box aufspielen oder kann man das Ganze irgendwie ausführen, so als ob man eine Box bedient?