Dbox2:Development:README.3rdparty.de (Oldmake) veraltet

Aus TuxBoxWIKI
Version vom 16. Mai 2018, 12:02 Uhr von Dbt (Diskussion | Beiträge) (zu Archiv Development verschoben)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
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.

Flagge en.jpg 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.

Verweise

siehe auch



Abgerufen von „https://wiki.tuxbox-neutrino.org/w/index.php?title=Dbox2:Development:README.3rdparty.de_(Oldmake)_veraltet&oldid=17697“