Dbox2:Development:README.3rdparty.de (Oldmake) veraltet
Inhaltsverzeichnis
English: Development:README.3rdparty.en
Allgemeines
Und so baut man neue Tools in das cdk ein
Zunächst macht man sich Gedanken darüber, ob das, was man einbauen will, Sinn macht. Wenn man meint, die Idee wäre gut, dann kann man anfangen sie zu integrieren.
Handelt es sich hierbei um eigene Software oder um bis zur Unkenntlichkeit veränderte Software, so ist das hier nicht das passende Dokument. Handelt es sich hingegen um veränderte Software anderer Leute, so nehme man den unveränderten Quellcode und erstelle dazu ein passendes Patch. Das geht mit dem Kommando
"diff -Naur paket.orig paket > paket.diff"
Der erstellte Patch gehört in das Verzeichnis
$HOME/tuxbox-cvs/cdk/Patches.
Es werden keine Versionsinformationen an den Dateinamen angehängt.
Was nun noch fehlt sind ein paar Eintraege in folgenden Dateien:
$HOME/tuxbox-cvs/cdk/Makefile.am $HOME/tuxbox-cvs/cdk/configure.ac $HOME/tuxbox-cvs/cdk/rules-archive $HOME/tuxbox-cvs/cdk/rules-make $HOME/tuxbox-cvs/cdk/rules-install
Beginnen wir mit 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. Diese werden mit Semikolon voneinander getrennt.
z.B. paket-1.0.tar.gz;http://www.pakethome.de/download
Als nächstes zu rules-make
Wieder braucht man eine Zeile pro Paket und wieder werden die Einträge mit Semikolon getrennt. Diesmal sind es allerdings ein paar mehr und zwar die Folgenden:
- Bezeichner fuer 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.
Was mit Versionsnummer gemeint ist sollte jedem klar sein.
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.
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.
Zu guter letzt traegt 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
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 ist wieder kürzer
Falls die Installation von Hand im Makefile.am geregelt wird, reicht es, hier den Bezeichner in eine eigene Zeile zu schreiben. Ansonsten nimmt man in der Regel folgenden Eintrag:
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 Sektion 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: TUXBOX_RULES_MAKE(paket)
erstellt Variablen, aus den Daten in rules-install, rules-make und rules-install, die in Makefile.am benutzt werden koennen. 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
Wer Makefiles kennt, der hat es leicht. Diese Datei ist sozusagen der Rohbau des Makefiles und unterscheidet sich nur durch die Variablen, die durch den Aufruf von configure ersetzt und in ein Makefile geschrieben werden.
Regeln, die zu einem Paket gehören, werden wie der oben gewählte Bezeichner mit einem Punkt vorangestellt genannt.
Am Ende jeder Regel steht "touch $@". Dieser Befehl erstellt eine Datei mit dem Namen der aktuellen Regel. Dadurch wird gekennzeichnet, dass eine Regel vollständig durchlaufen wurde.
Beispiel für eine Regel:
.paket: .bootstrap @DEPENDS_packet@ @PREPARE_packet@ cd @DIR_packet@ && \ $(BUILDENV) \ ./configure \ --build=$(build) \ --host=$(target) \ --prefix= && \ $(MAKE) all && \ @INSTALL_packet@ @CLEANUP_packet@ touch $@
$(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 im Makefile.am.
Weiterhin gibt es in Makefile.am 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. Auch hier muss man an geeigneter Stelle den Regelnamen aufführen, so dass die Markierung, die nach erfolgreichem Bauen angelegt wurde, entfernt werden kann.
Grundlagen - Installation - Debug-Mode - Hardware - CDK/Development
LCars - Neutrino - Enigma - Plugins - Spiele - Software - Tools - Howto - FAQ - Images
Hauptseite - News - Alle Artikel - Bewertungen - Gewünschte Seiten - Index - Neue Artikel - Impressum - Team
Hilfeportal - Seite bearbeiten - Bilder - Links - Tabellen - Textgestaltung