Dbox2:Development:3rdparty Tools (veraltet)

Aus TuxBoxWIKI
Version vom 21. August 2011, 21:52 Uhr von WikiBot (Diskussion | Beiträge) (Bot: Fixing redirects)
Wechseln zu: Navigation, Suche


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

Hier soll eine kurze Anleitung gegeben werden, wie man sich ein Tool mit Hilfe von Newmake in sein CDK einbauen kann, um es auf der DBox betreiben zu können. Als Tools sind hier beispielsweise Programme zu verstehen, welche von Drittanbietern weltweit auf deren Servern zur Verfügung gestellt werden. Viele davon dürften auch aus den verschiedensten Linux-Distributionen bekannt sein. Es würde auch mit eigenen Programmen funktionieren, sofern das Schema der Verteilung ähnlich vonstatten geht.

Hinweis:
Der hier beschriebene Weg beschreibt nicht die Möglichkeit, ein Tool mittels Customizing einzubauen. Dies ist ein anderes Thema.


Vorbereitung

Folgend wird schematisch das Tool und die Quelle aus dem man das Tool erzeugt wird als

  • Paket

bezeichnet, wobei Programm und Paket meist vom Namen her gleich sind und Paket zusätzlich Versionsangaben und Dateierweiterungen enthalten.


Das Schema zum Kompilieren und installieren eines so eingebauten Tools könnte man in etwa wie folgt umschreiben:

  • (Paket downloaden) - Paket auspacken - (Paket patchen) - Programm kompilieren - Programm installieren - ausgepacktes Paket löschen


Zunächst sollte man sich überlegen was man einbauen möchte. Dazu kläre man, wo dieses Paket als Download zu finden ist. Häufig handelt es sich hierbei um GNU-Tools von denen es bereits einige für die DBox im CDK gibt. Es kann also sein, dass es bereits vorhanden sein könnte. Ist das geklärt, nehmen wir an, das Tool ist unter dieser Adresse zu finden: 

http://www.anbieter.net/downloads/paket-1.0.tar.gz

Möglicherweise gibt es auf der Anbieterseite auch einige Patches, die man benötigen möchte/muss oder man hat selbst einen Patch erstellt. Dann kann man diesen auch verwenden. Patche werden unter 

../cdk/Patches

abgelegt. Hat man selbst Änderungen am Paket gemacht und möchte davon einen Patch haben, erfolgt dies mit: 

"diff -Naur paket.orig paket > paket.diff"


Dateien anpassen

Um jetzt die notwendigen Anpassungen vorzunehmen müssen diese Dateien angepasst werden: 

$HOME/<CVSDIR>/cdk/configure.ac
$HOME/<CVSDIR>/cdk/Makefile.am
$HOME/<CVSDIR>/cdk/rules-archive
$HOME/<CVSDIR>/cdk/rules-make
$HOME/<CVSDIR>/cdk/rules-install

Wir ordnen unser Programm der Gruppe contrib-apps zu, daher benötigen wir 

$HOME/<CVSDIR>/cdk/make/contrib-apps.mk


rules-archive

Hier gehört genau eine Zeile pro Paket hinein, und zwar der Name des Archivs, sowie eine oder mehrere http- oder ftp-Adressen, von denen das Archiv direkt geladen werden kann. Dafür zerlegen wir den oben genannten Download-Link. Die Einträge werden mit Semikolon voneinander getrennt.

z.B. 

paket-1.0.tar.gz;http://www.anbieter.net/downloads


rules-make

auch hier braucht man eine Zeile pro Paket und die Einträge werden auch hier mit Semikolon getrennt. Diesmal sind es allerdings ein paar mehr und zwar die Folgenden:

  • Bezeichner für die Software
  • Versionsnummer der Software
  • Verzeichnisname nach dem entpacken der Software
  • Archivname und Name eventueller Patches (durch Doppelpunkt getrennt)
  • Eine oder mehrere Regeln zum Bearbeiten des Archivs und vorhandender Patches


Der Bezeichner wird wieder in rules-install, configure.ac und Makefile.am zum Einsatz kommen. Er ist prinzipiell frei wählbar, sollte aber dennoch möglichst viel mit dem Paketnamen gemeinsam haben. 

paket;1.0;paket-1.0;paket-1.0.tar.gz;extract:paket-1.0.tar.gz


Was mit Versionsnummer gemeint ist sollte jedem klar sein. 

paket;1.0;paket-1.0;paket-1.0.tar.gz;extract:paket-1.0.tar.gz


Der darauf folgende Verzeichnisname muss dem Pfad entsprechen, der in dem zu entpackenden Archiv gespeichert ist. Ist kein Pfad gespeichert, so muss man einen Pfad möglichst sinnvoll wählen und später bei den Regeln anstatt extract dirextract verwenden. 

paket;1.0;paket-1.0;paket-1.0.tar.gz;extract:paket-1.0.tar.gz


Archivname sollte auch klar sein. Falls zusätzliche Dateien existieren, die für das Paket benutzt werden, seien es diffs oder zusätzliche Archive, so gibt man deren Namen ohne Verzeichnis und durch Doppelpunkt getrennt an. 

 paket;1.0;paket-1.0;paket-1.0.tar.gz;extract:paket-1.0.tar.gz


Zu guter letzt trägt man die Regeln ein, nach denen mit dem Archiv und seinen Patches verfahren werden soll: 

extract    - extrahiert ein Paket
dirextract - extrahiert ein Paket in das angegebene Verzeichnis
patch      - patcht eine diff Datei in ein extrahiertes Paket

paket;1.0;paket-1.0;paket-1.0.tar.gz;extract:paket-1.0.tar.gz

Hinweis:
Für weitere Regeln kann man einen Blick in die Datei rules-make werfen.

z.B. sieht das dann so aus; 

paket;1.0;paket-1.0;paket-1.0.tar.gz;extract:paket-1.0.tar.gz

oder falls ein patch vorhanden ist: 

paket;1.0;paket-1.0;paket-1.0.tar.gz:paket.diff;extract:paket-1.0.tar.gz;patch:paket.diff


rules-install

Man nimmt in der Regel folgenden Eintrag vor: 

paket;make:install:DESTDIR=TARGET

Es können mehrere Befehle angegeben werden, diese sind per Semikolon von einander zu trennen. Befehle und zugehörige Parameter werden durch Doppelpunkt getrennt. DESTDIR=TARGET wird benutzt, um make den Pfad des cdkroots mitzuteilen. Einige Pakete benutzen davon abweichende Variablennamen oder können ausschließlich ueber --prefix zur configure-zeit den Zielpfad mitgeteilt bekommen.


configure.ac

Hier sucht man sich die passende Stelle in der Datei aus (an den vorhandenen Einträgen orientieren) und fügt dort entweder TUXBOX_RULES_MAKE(...) oder TUXBOX_RULES_MAKE_EXDIR(...) ein. Anstatt der Punkte benutzt man den in rules-make gewählten Bezeichner.

Beispiel: 

#
# contrib apps
#
TUXBOX_RULES_MAKE(paket)

Dieser Eintrag erstellt Variablen, aus den Daten in rules-install, rules-make und rules-install, die in contrib_apps.mk benutzt werden können. Es werden die folgenden Variablen definiert:

  • DEPENDS_paket - benötigte Archive und Patches
  • PREPARE_paket - Kommandos zum extrahieren und patchen des Paketes
  • DIR_paket - Name des Verzeichnisses, in das entpackt wurde
  • INSTALL_paket - Installationsbefehle
  • CLEANUP_paket - Befehle zum Entfernen von Dateien nach Bau und Installation
TUXBOX_RULES_MAKE_EXDIR(paket)

tut prinzipiell dasselbe, hat jedoch den Unterschied, dass es für Pakete benutzt wird, bei denen das Bauen nicht im Quellverzeichnis selbst passieren soll. Zusätzlich wird die folgende Variable definiert: 

CONFIGURE_paket - Aufruf des Konfiurationsskriptes des Paketes


Makefile.am

Im Gegensatz zum altem Makevorgang (Oldmake) werden hier quasi nur Verweise auf einzelne mk-Files eingetragen aus denen beim configure später dann ein Makefile generiert wird. In diesem konkreten Beispiel haben wir bereits ins Auge gefasst, dass unser Programm zur Gruppe contrib-apps gehört, daher braucht man hier keinen Eintrag vorzunehmen, da dieser bereits schon vorhanden ist. 

# A number of libraries, some of which necessary for neutrino or enigma
include make/contrib-apps.mk

Der eigentliche Eintrag erfolgt dann logischer Weise in 

../cdk/make/contrib-apps.mk


contrib-apps.mk

Diese Datei ist sozusagen ein Teil des Rohbaus des Makefiles und unterscheidet sich nur durch die Variablen, die durch den Aufruf von configure ersetzt und in ein Makefile geschrieben werden.

Hier steht zu Beginn der Datei folgende Zeile, den wir um unser Programm erweitern: 

#######################
#
#   contrib apps
#

contrib_apps: bzip2 console_data console_tools fbset lirc lsof dropbear ssh tcpdump bonnie lufs kermit wget ncftp paket

Hier wurde das target (contrib_apps) so erweitert, dass später mit dem Aufruf von 

make contrib_apps

unser Programm zusammen mit allen anderen gebaut wird. Was noch fehlt, ist nun auch eine Regel für unser Programm selbst.

Regeln, die zu einem Paket gehören, werden wie der oben gewählte Bezeichner vorangestellt genannt.

Beispiel für eine Regel: 

paket: .bootstrap @DEPENDS_paket@
	@PREPARE_paket@
	cd @DIR_paket@ && \
		$(BUILDENV) \
		./configure \
			--build=$(build) \
			--host=$(target) \
			--prefix= && \
		$(MAKE) all && \
		@INSTALL_paket@
	@CLEANUP_paket@
	touch $@

Detailinformationen

$(BUILDENV) ist ein Makro, das eine Menge an oft gebrauchten Umgebungsvariablen enthält, wie z.b. CC, CFLAGS usw. Ab und zu kann es vorkommen, dass ein Paket andere oder zusätzliche Variablen braucht. Diese können unterhalb von $(BUILDENV) angegeben werden. Beispiele dazu findet man in den anderen mk-Files.

Am Ende jeder Regel steht "touch $@". Dieser Befehl erstellt eine Datei mit dem Namen der aktuellen Regel. In unserem Fall: 

../cdk/.deps/paket

Dadurch wird gekennzeichnet, dass eine Regel vollständig durchlaufen wurde. Mit sogenannten Cleantargets können einige dieser Kennzeichnungen entfernt werden, um später eine Neukompilierung zu erzwingen. Hierfür muss man diesen Eintrag ergänzen: 

CONTRIB_DEPSCLEANUP = rm -f .deps/bzip2 .deps/console_data .... .deps/ncftp .deps/paket

Weiterhin gibt es Regeln, die verschiedene Regeln gruppieren und letztendlich zu einer globalen Regel ("all") zusammengefasst werden. Dort, wo das hinzugefügte Paket kategorisch am besten einzuordnen ist, fügt man den Eintrag hinzu, z.B. 

devel = .gdb .strace .paket

Am Ende der Datei ist die Regel zum Säubern der Umgebung zu finden. 

@CLEANUP_paket@

Auch hier muss man an geeigneter Stelle den Regelnamen aufführen, so dass die Markierung, die nach erfolgreichem Bauen angelegt wurde, entfernt werden kann.

für Flash

Um auch unser Programm flashtauglich zu machen, wird hierfür auch noch eine Regel benötigt: 

if TARGETRULESET_FLASH
flash-paket: $(flashprefix)/root/bin/paket

$(flashprefix)/root/bin/paket: paket | $(flashprefix)/root
	rm -f $(flashprefix)/root/bin/paket
	@$(INSTALL) -d $(flashprefix)/root/bin
	$(INSTALL) $(targetprefix)/bin/paket $(flashprefix)/root/bin
@FLASHROOTDIR_MODIFIED@

endif

Somit wäre auch ein target für den Einbau in ein Image vorhanden.


Kompilieren

Nun sollte, wenn alles stimmt, erledigt sein. Es muss nun noch konfiguriert und kompilert werden. Der Aufruf zum Bau unseres Programmes erfolg mit 

make paket
make flash-paket

oder um alle contrib-apps zu bauen 

make contrib_apps

Hinweis: Contrib-Apps sind als Zugabe vorgesehen und werden nicht automatisch beim Erstellen von Images oder Yadds mitgebaut bzw. installiert. Daher sollte man diese in ein Customization einpflegen.



Abgerufen von „https://wiki.tuxbox-neutrino.org/w/index.php?title=Dbox2:Development:3rdparty_Tools_(veraltet)&oldid=14687“