Eigene Pakete einbinden: Difference between revisions
(→Minimalinvasive Variante: New section) |
|||
Line 55: | Line 55: | ||
== Minimalinvasive Variante == |
== Minimalinvasive Variante == |
||
Man kann die obigen Schritte auch völlig ausserhalb der OpenEmbedded- und OpenMoko-Verzeichnisse ausführen um keine Probleme bei eventuellen zukünftigen Updates zu bekommen. Das ist im Prinzip wie eine neue Distribution aufbauend auf OpenMoko zu machen, welches an sich schon eine Distribution aufbauend auf OpenEmbedded ist. |
|||
Dazu legt man einen neuen Verzeichnisbaum <tt>openmoko-sar</tt> neben <tt>oe</tt> und <tt>openembedded</tt> an: |
|||
$OPENMOKODIR |
|||
| |
|||
|-> oe |
|||
| | |
|||
| |-> classes |
|||
| | | |
|||
| | |-> ... |
|||
| |-> packages |
|||
| | | |
|||
| | |-> images |
|||
| | |-> ... |
|||
| |->... |
|||
|-> openembedded |
|||
| | |
|||
| |->... |
|||
|-> openmoko-sar |
|||
| | |
|||
| |-> packages |
|||
| | | |
|||
| | |-> images |
|||
| | | | |
|||
| | | |-> openmoko-sar-devel-image.bb |
|||
| | | |-> openmoko-sar-image.bb |
|||
Zum Testen kann man erstmal eigene Image-Rezepte in dieser Struktur anlegen die auf den normalen Image-Rezepten aus <tt>$OPENMOKODIR/oe/packages/images/</tt> basieren (d.h. Kopie, mit eigenem Namen, <tt>require</tt>-Direktive in <tt>openmoko-sar-devel-image.bb</tt> anpassen). |
Revision as of 12:06, 26 June 2007
Eigene Pakete in Openmoko einbinden
Openmoko nutzt das Build-System von OpenEmbedded, welches auf Bitbake beruht. Um nun eine eigene Anwendung in Openmoko zu integrieren, muss man zunächst dafür sorgen, dass Bitbake diese Anwendung auch zu einem ipkg-Paket zusammenbauen kann. Die Steuerung von Bitbake funktioniert über .bb Dateien.
Bitbake bietet verschiedene Module an, die dabei helfen, sich den aktuellen source code einer Anwendung zu besorgen. Darunter befindet sich auch ein Modul, dass die aktuelle Version des Quelltextes aus einem SVN-Repository auscheckt.
Beispiel für .bb Datei
Das Beispielprojekt besteht aus genau 2 Dateien: dem Quelltext in astar.cpp und dem Makefile. Die Verzeichnisstruktur sieht folgendermaßen aus
$OPENMOKODIR/oe/packages/a-star | |-> a-star.bb |-> files | |-> Makefile |-> astar.cpp
Die a-star.bb hat folgenden Inhalt:
DESCRIPTION = "A-Star (Packaging Demo)" LICENSE = "GPL" SECTION = "extra" PR = "r1" SRC_URI = "file://Makefile \ file://astar.cpp" S = "${WORKDIR}" do_install() { install -d ${D}${bindir} install ${WORKDIR}/astar ${D}${bindir} }
Unter SRC_URI wird angegeben wo der Quelltext abgelegt ist. Dort ist es dann z.B. auch möglich ein SVN-Repository anzugeben. IM Abschnitt do_install() ist festgelegt, an welche Stelle im Dateisystem die Programmdateien kopiert werden sollen.
Paket automatisch mit Openmoko bauen lassen
Um ein Paket zusätzlich zu den standardmäßig integrierten Paketen Paketen kompilieren und packetieren zu lassen, reicht es den Paketnamen unter $OPENMOKODIR/build/conf/local.conf mittels DISTRO_EXTRA_RDEPENDS = $PAKETNAME hinzuzufügen.
Paket ins openmoko-devel-image integrieren
Um das Paket dann noch automatisch beim Erzeugen eines neuen Images mit in das Dateisystem zu installieren, ist es nötig das Bitbake-Rezept des openmoko-devel-image zu modifizieren. Dieses findet sich unter $OPENMOKODIR/oe/packages/images/openmoko-devel-image.bb. Damit bei Updates die Änderungen nicht stets überschrieben werden, bietet es sich an, die Änderungen als Patch zu sichern. Dies kann man wie unter [1] beschrieben durch folgende Kommandos, die man mit unverändertem openmoko-devel-image.bb-Rezept in $OPENMOKODIR/openmoko ausführt, erreichen:
quilt new some_patch_name.patch quild add trunk/oe/packages/images/openmoko-devel-image.bb # Jetzt in openmoko-devel-image.bb zu PACKAGE_INSTALL eine neue Zeile mit dem Paketnamen # und einem Backslash anhängen quilt refresh
Damit landen die Änderungen als Patch unter $OPENMOKODIR/openmoko/patchesund werden beim Bauen von openmoko-devel-image mit eingepflegt.
Minimalinvasive Variante
Man kann die obigen Schritte auch völlig ausserhalb der OpenEmbedded- und OpenMoko-Verzeichnisse ausführen um keine Probleme bei eventuellen zukünftigen Updates zu bekommen. Das ist im Prinzip wie eine neue Distribution aufbauend auf OpenMoko zu machen, welches an sich schon eine Distribution aufbauend auf OpenEmbedded ist.
Dazu legt man einen neuen Verzeichnisbaum openmoko-sar neben oe und openembedded an:
$OPENMOKODIR | |-> oe | | | |-> classes | | | | | |-> ... | |-> packages | | | | | |-> images | | |-> ... | |->... |-> openembedded | | | |->... |-> openmoko-sar | | | |-> packages | | | | | |-> images | | | | | | | |-> openmoko-sar-devel-image.bb | | | |-> openmoko-sar-image.bb
Zum Testen kann man erstmal eigene Image-Rezepte in dieser Struktur anlegen die auf den normalen Image-Rezepten aus $OPENMOKODIR/oe/packages/images/ basieren (d.h. Kopie, mit eigenem Namen, require-Direktive in openmoko-sar-devel-image.bb anpassen).