Entwicklungs Umgebung

Hi,
die Linux Distribution ist eigentlich egal, sie sollte nur halbwegs aktuell sein. Ein sehr guter Code Browser für grössere Projekte ist sicherlich der Source Navigator. Den würde ich aber nur zum editieren benutzen. make würde ich ganz normal per Kommandozeile starten.

Mfg
Holger

Zitat

Original von rfehr
Hat keiner einen Tipp, es gibt doch genügen Leute die
Plugins entwickeln.

Roland

Nicht jeder Thread hat innerhalb 20 min ne passende Antwort.

...denk auch mal über VMWare nach. Da sparst du dier viel Arbeit mit.

Gruß
Wicky

Ich habe mein Plugin über printf oder syslog ausgaben debuggt. Ein wirkliches debuggen eines kompletten VDRs ist nicht so trivial, da der VDR viele Threads startet. Theoretisch kannst du auf deinem VDR einen gdbserver starten und dich z.B. mit dem DDD connecten und debuggen. Mir war es nicht gegeben. Es war aber auch nicht notwendig.
Der DDD ist aber der beste Debugger auch wenn er etwas ungewohnt daherkommt, vor allem wenn man Windows IDEs gewohnt ist.

Ich arbeite eigentlich nur mit vi und make auf der Kommandozeile, natürlich mit mehreren Konsolenfenstern - und das Debuggen geschieht mit gdb, den ich einfach per attach <pid> an den laufenden VDR hänge. Dann sind auch die Symbole des Plugins bekannt und man kann Haltepunkte im Plugin-Source setzen. Von da geht's dann weiter

EDIT:
Mein Dev-System ist übrigens ein Sarge auf ner USB-Platte, in das ich mich vom laufenden VDR per chroot einschalte - da kann ich dann schön abgeschottet mit Echtdaten testen...

EDIT2:
Unter Windows arbeite ich übrigens auch am liebsten mit Fancy IDE's

Meine Entwicklungsumgebung:

- VDR mit Softdevice-Plugin
- GEdit
- 3-4 XTerms (1x VDR, 1xSyslog, 1xKompilieren, 1xMan-Pages)

Bis jetzt bin ich damit immer noch am besten klar gekommen. Eine ausgwachsene IDE finde ich zu überladen. Alles kann man zwar nicht damit machen, aber für das, was ich bis jetzt zusammengeschraubt habe, reicht es

Gruß,
Nordlicht

Ich mount mit

mount -o bind /video0 /mnt/usb/vdr-devel-sarge/video0

das Videoverzeichnis ins chroot und wechsel anschliessend selbst hinein (mit /proc übrigens analog). Setupdateien hat der Debug-VDR natürlich andere als der produktive. Ausgegeben wird, wenn ich sowas wie das Burn-Plugin bearbeite mit skincurses auf der Konsole, bei Sachen wie text2skin mit softdevice auf nem X-Windows eines anderern Rechners. Und wenn ich's am Fernseher ausprobieren will, nachdem der Rest keine groben Fehler mehr zeigt, kopier ich die .so aus dem chroot ins richtige lib-Verzeichnis.

Moin,
Meine Entwicklungsumgebung sieht so aus:
Gen2VDR unter VmWare
Editiert wird uebr SamBa mit Slickedit und kompilert in der ssh Shell.
Einen Debugger nutze ich nur in Ausnahmefaellen (so ca einmal im Schaltjahr ), das wird alles mit printf's gemacht.
Ein ehemaliger Abteilungsleiter hat mal zu mir gesagt, dass er es fuer ein auesserst schlechtes Zeichen haelt, falls ein Entwickler beim Vorstellungsgespraech angibt sich gut it Debuggern auszukennen ...
Ein vernuenftiges Log-System ist wesentlich besser.

P.S. Oh durch diesen Eintrag wurde ich in den Ritterstand erhoben

Zitat

Original von helau
Ein ehemaliger Abteilungsleiter hat mal zu mir gesagt, dass er es fuer ein auesserst schlechtes Zeichen haelt, falls ein Entwickler beim Vorstellungsgespraech angibt sich gut it Debuggern auszukennen ...
Ein vernuenftiges Log-System ist wesentlich besser.

Dann hat der Abteilungsleiter aber nicht wirklich Ahnung. Klar ist ein gutes Logsystem für alles was passieren kann von elementarer Bedeutung, aber um einen Fehler der nicht passieren darf zu finden ein Programm mit Logausgaben in jeder zweiten Zeile zu spicken, um dem auf die Spur zu kommen, ist totaler tinnef.

Davon mal abgesehen, haben wir hier kürzlich erst einen Fall von Speicherkorruption gehabt, den zwei Entwickler mit ihren tollen Log-Ausgaben in zwei Tagen nicht gefunden haben. Einmal Debugger, zwei Haltepunkte und ein Watchpoint, und der Fehler war in fünf Minuten bis auf die Quelltextzeile genau identifiziert.

Also, Log-Ausgaben einem Debugger vorzuziehen, also ehrlich

EDIT:
Ich halte es übrigens meist so dass die ausführlichen Logausgaben mich schnell zum ersten möglichen Haltepunkt führen sollen und von dort aus wird ggfs. gesteppt, oft aber auch nur ein paar Werte abgeglichen.

Hi,

meine Umgebung: Eclipse mit CDT, compile per ganz normalem Make (-file).

Viele Grüße
Christian

Zitat

Original von helau

Ein ehemaliger Abteilungsleiter hat mal zu mir gesagt, dass er es fuer ein auesserst schlechtes Zeichen haelt, falls ein Entwickler beim Vorstellungsgespraech angibt sich gut it Debuggern auszukennen ...
Ein vernuenftiges Log-System ist wesentlich besser.

es gibt auch Abteilungsleiter die das Debuggen weit höher bewerten

Zitat

Original von helau
P.S. Oh durch diesen Eintrag wurde ich in den Ritterstand erhoben

Gratulation !!

Wer bei modernen Debuggern noch ausschliesslich mit LOGs arbeitet is aber auch mal selber schuld ;).

arghgra

Ich persönlich kann einem guten Log File Mechanismus nur ZUSTIMMEN.
Offensichtlich ist es einigen nicht klar, dass es manchmal halt einfach NICHT MÖGLICH ist, sich mit einem Debugger an das System zu klemmen. Z.B. bei komplexen Embeddesystem, die am besten noch irgendwo im Feld stehen !!
Aus meiner Erfahrung heraus passiert es aber leider auch, dass Fehler bei aktiviertem Log dummerweise auch verschwinden können, weil sich dann das Zeitverhalten ändert ! Dann wird's erst richtig schwierig ...

Als Entwicklungsstem habe ich meinem schnellen Hauptrechner, der auch nochmal eine alte DVB-T Hauppauge + xine plugin. hat
Als Entwicklungsumgebung benutze ich KDevelop. Eclipse + CDT hatte ich mal ausprobiert, fand ich aber mächtig langsam , ausserdem fand ich die Compilermeldungen dort etwas verwirrend. Manchmal benutze ich aber auch einfach nur nano + make.

Zitat

Original von arghgra
Wer bei modernen Debuggern noch ausschliesslich mit LOGs arbeitet is aber auch mal selber schuld ;).

arghgra

Ausschliesslich sagt ja auch keiner - aber wer weniger Fehler macht und ein vernuenftiges Log-Konzept hat, der braucht (fast) nie einen Debugger