Dbox2:Plugins:Tutorial (veraltet)

Aus TuxBoxWIKI
Wechseln zu: Navigation, Suche


HINWEIS:

Diese Kategorie bzw. dieser Artikel basiert auf auf dem alten Buildsystem "Oldmake", welches ab Januar 2009 durch das jetzt im CVS-Head befindliche "Newmake" abgelöst wurde. Es ist relativ sicher, dass viele Funktionen nicht mehr aktiv unterstützt werden oder nicht mehr funktionieren. Es besteht aber die Möglichkeit "Oldmake" weiterhin zu warten. Der letzte funktionsfähige Stand wurde im CVS mit dem Tag

last_oldmake_head

markiert und ein entsprechender Branch

oldmake

angelegt, so dass das Verfahren, wenn auch eingeschränkt, weiter verwendet werden kann. Von den meissten aktiven Entwicklern wird dieser Branch jedoch nicht mehr weiter gepflegt, so dass es am Nutzer selbst liegt, notwendige Änderungen im Entwicklerforum mitzuteilen oder sofern die Möglichkeit besteht, selbst entsprechende Änderungen ins CVS zu schreiben.


Review-KandidatDieser Artikel befindet sich derzeit im Reviewprozess. Hilf mit, ihn zu verbessern! Falls du bei weiteren Artikeln helfen willst, findest du hier eine Auswahl offener Artikel.

Allgemeines

Es gibt viele Leute, die eigene Ideen für Verbesserungen der Dbox2-Software haben.

Im Forum heißt es da oft: Ist doch OpenSource, mach es halt selber.

Doch das ist gar nicht so einfach, denn nicht jeder ist ein Programmierer und kann die bestehenden Quelltexte lesen wie andere ein Buch. Dazu kommt noch, dass man eine Menge anderer Dinge tun muss, bevor man endlich damit beginnen kann seine neue Idee zu verwirklichen.

Man muss erst einmal eine Programmier-Umgebung (CDK) aufbauen, die ausführbare Dateien für die DBox2 erstellen kann. Das funktioniert am besten unter Linux.

Hat man diese Einstiegshürde erst einmal gemeistert, dann steht man gleich vor dem nächsten Problem: Wo anfangen?

Meiner Meinung nach können die meisten Ideen durch ein Plugin realisiert werden.

Und genau darum soll es auch in diesem Tutorial gehen. Wie erstelle ich ein eigenes Plugin und binde dieses in das CDK und später in die DBox2 ein.


Plugin-Grundgerüst

Um ein eigenes Plugin zu erstellen braucht man zunächst einmal die eigentlichen Quelltexte des Plugins.

Im einfachsten Fall sind dies eine .c und eine .h Datei, in unserem Tutorial werden dies testplugin.c und testplugin.h sein.

Außerdem müssen wir dem Programm, das das Plugin aufrufen soll (Neutrino oder Enigma) mitteilen, welche Eigenschaften unser neues Plugin hat, bzw. welche Ressourcen es benötigt.

Dies wird mit einer Plugin-Konfigurationsdatei (testplugin.cfg) erreicht, deren Inhalt folgendermaßen aussieht

type=2
name=Testplugin
desc=Test zur Pluginerstellung
needfb=0
needlcd=0
needrc=0
needoffsets=0

Eine Erklärung, was die einzelnen Parameter der .cfg-Datei bedeuten, findet man hier.


Hello World

Nun zum eigentlichen Programm. Da es mir hauptsächlich darum geht zu zeigen, wie man ein eigenes Plugin in das CDK einbindet, hier das einfachste aller Beispiele:

testplugin.h

#include "stdio.h"
#include "plugin.h"

testplugin.c

#include "testplugin.h"

void plugin_exec(PluginParam *par)
{
	printf("Hallo Welt\n");
	return;
}

Das ist zugegebenermaßen kein Plugin mit einer supertollen Funktion, aber es reicht um alles weitere testen zu können. Startet man dieses Plugin, so wird der Text "Hallo Welt" auf der Konsole ausgegeben, nicht mehr, aber auch nicht weniger.


Einbindung des neuen Plugins ins CDK

Um das neue Plugin-Verzeichnis und die neuen Quelltext-Dateien ins CDK einzubinden, muss als erstes im Plugin-Verzeichnis die Datei Makefile.am erstellt werden.


Hier einmal die Makefile.am unseres Test-Plugins als Beispiel:


AM_CPPFLAGS = \
	@FREETYPE_CFLAGS@ \
	-I$(top_srcdir)/include

noinst_LTLIBRARIES = testplugin.la

testplugin_la_SOURCES = testplugin.c

if BOXTYPE_DREAMBOX
testplugin_la_CFLAGS = -DOLDFT
endif

testplugin_la_LIBADD = \
	@FREETYPE_LIBS@

testplugin_la_LDFLAGS = -rpath $(PLUGINDIR) -module -avoid-version

install-exec-local:
	install -d $(DESTDIR)$(PLUGINDIR)
	install -d $(DESTDIR)$(CONFIGDIR)
	install -d $(DESTDIR)$(CONFIGDIR)/testplugin
	$(LIBTOOL) --mode=install install testplugin.la $(DESTDIR)$(PLUGINDIR)
	install -m 0644 $(srcdir)/testplugin.cfg $(DESTDIR)$(PLUGINDIR)
 

Dann muss man nur noch im Verzeichnis

~/yadi/tuxbox-cvs/apps/tuxbox/plugins

die beiden Dateien configure.ac und Makefile.am editieren.

In der Datei configure.ac werden ab Zeile 32 die Makefiles der einzelnen Plugins aufgelistet. Hier muss man das neue Plugin ergänzen.

AC_OUTPUT([
Makefile
include/Makefile
fx2/Makefile
fx2/lemm/Makefile
fx2/master/Makefile
.
.
.
enigma/ngrabstop/Makefile
enigma/dslconnect/Makefile
enigma/dsldisconnect/Makefile
testplugin/Makefile
tuxbox-plugins.pc
])

Als letzten Schritt zur Einbindung des neuen Plugins muss noch die Makefile.am im Plugins-Verzeichnis ergänzt werden.

AUTOMAKE_OPTIONS = gnu

if BOXTYPE_DREAMBOX
SUBDIRS = \
	include tuxmail tuxtxt tuxcom fx2 enigma testplugin 
else
SUBDIRS = \
	include tuxmail tuxtxt tuxcom fx2 vncviewer enigma testplugin
endif 

pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = \
	tuxbox-plugins.pc

Das war's auch schon. Durch einen Aufruf des Compilers (siehe nächster Abschnitt) werden nun die restlichen benötigten Dateien automatisch erzeugt.


Kompilieren des Plugins

Hat man bisher alles korrekt ausgeführt, dann kommt jetzt der einfache Teil Smile.png

Man wechselt auf der Kommandozeile ins CDK-Verzeichnis

cd ~/yadi/tuxbox-cvs/cdk

Dort führt man die folgenden 2 Befehle aus

rm .deps/plugins
make plugins

Beim ersten Aufruf dieser Zeilen werden die benötigten Make-Dateien vom System erstellt und anschließend ausgeführt.

Bei weiteren Aufrufen werden die Plugins, bei denen etwas im Quelltext geändert wurde, neu kompiliert.

Nur ein einzelnes Plugin neu zu kompilieren ist mir mit meinem momentanen Wissensstand noch nicht gelungen, was aber auf keinen Fall heißt, dass es nicht möglich ist.

Wurde das Plugin fehlerfrei compiliert, dann befinden sich anschließend 3 neue Dateien im Verzeichnis

 ~/yadi/dbox/cdkroot/lib/tuxbox/plugins

In unserem Beispiel sind die folgenden Dateien dort neu:

 ~/yadi/dbox/cdkroot/lib/tuxbox/plugins/testplugin.so

Dies ist das eigentliche Binary, die Plugin-Datei.

 ~/yadi/dbox/cdkroot/lib/tuxbox/plugins/testplugin.cfg

Dies ist die von uns erstellte Konfigurationsdatei, in der das Hauptprogramm vor dem Ausführen des Plugins nachsieht, welche Ressourcen unser Plugin benötigt.

 ~/yadi/dbox/cdkroot/lib/tuxbox/plugins/testplugin.la

Wofür diese Datei genau ist, weiß ich auch nicht genau, vielleicht kann das mal ein schlauerer Mensch ergänzen Smile.png


Testen des Plugins

Um das Plugin auf der DBox2 zu testen, gibt es mehrere Möglichkeiten.

1. Man kopiert diese 3 Dateien per FTP auf die DBox2 ins Verzeichnis

 /lib/tuxbox/plugins/

Dabei ist zu beachten, dass die .so Datei ausführbar sein muss. Dies kann man entweder mit seinem FTP-Programm erledigen, oder aber per telnet auf der DBox2:

cd /lib/tuxbox/plugins/
chmod +x testplugin.so


2. Man richtet einen NFS-Server auf seiner Entwicklungsmaschine ein und mountet das Pluginsverzeichnis direkt auf die DBox2

Wie man den NFS-Server einrichtet, hängt von der Entwicklungsmaschine ab, deshalb überspringe ich das einfach ;O)

Das Mounten auf der DBox2 erledigt man dann mit folgendem Befehl:

mount -t nfs <server-ip>:/<verzeichnis> /mnt/plugins -o ro,soft,nolock,udp,rsize=32768,wsize=32768

Bei meinem System sieht das dann so aus:

mount -t nfs 192.168.60.210:/home/chrrh/yadi/dbox/cdkroot/lib/tuxbox/plugins /mnt/plugins -o ro,soft,nolock,udp,rsize=32768,wsize=32768


Ist Punkt 1 oder Punkt 2 erledigt, kann man im z.B. bei Neutrino im Menü [d-box]->Service->Plugins neu laden die Plugins neu einlesen. Jetzt sollte in der Plugin-Liste das neue Plugin auftauchen und ganz normal über die Fernbedienung gestartet werden können.

Ich wünsche viel Spaß mit dem neuen Plugin und vor allem viel Erfolg beim Entwickeln eigener Plugins.