Eigene Pakete einbinden: Difference between revisions

From
Jump to navigation Jump to search
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Openmoko]]

== Eigene Pakete in Openmoko einbinden ==
== Eigene Pakete in Openmoko einbinden ==


Line 38: Line 40:
=== Paket automatisch mit Openmoko bauen lassen ===
=== 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 ===
=== 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 [http://wiki.openmoko.org/wiki/MokoMakefile#Developing_with_MokoMakefile] 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/patches''und werden beim Bauen von openmoko-devel-image mit eingepflegt.

== Minimalinvasive Variante ==

Man kann die obigen Schricodee 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 <code>openmoko-sar</code> neben <code>oe</code> und <code>openembedded</code> 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 <code>$OPENMOKODIR/oe/packages/images/</code> basieren (d.h. Kopie, mit eigenem Namen, <code>require</code>-Direktive in <code>openmoko-sar-devel-image.bb</code> anpassen). Später kann dann diese Verzeichnisstruktur in einem SVN residieren.

Um sie benutzen zu können benötigt man folgende Änderungen: in <code>setup-env</code>:
export BBPATH="${OMDIR}/build:${OMDIR}/oe:${OMDIR}/openembedded:"
zu
export BBPATH="${OMDIR}/build:${OMDIR}/oe:${OMDIR}/openembedded:${OMDIR}/openmoko-sar"
in <code>build/conf/local.conf</code> anhängen:
BBFILES := "${BBFILES} ${OMDIR}/openmoko-sar/packages/*/*.bb"

Und evt. noch als Bequemlichkeitsfeature: in <code>Makefile</code> einfügen:
.PHONY: %-image
%-image:
( source ./setup-env ; cd build ; bitbake -c build $*-image )

Dann sollte man mit <code>make openmoko-sar-devel-image</code> das neue Image bauen können. Bonuspunkt: Durch die Benamung mit dem Präfix <code>openmoko-</code> wird das Image automatisch von <code>make flash-qemu-local</code> gefunden und berücksichtigt.

Latest revision as of 12:14, 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 Schricodee 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). Später kann dann diese Verzeichnisstruktur in einem SVN residieren.

Um sie benutzen zu können benötigt man folgende Änderungen: in setup-env:

export BBPATH="${OMDIR}/build:${OMDIR}/oe:${OMDIR}/openembedded:"

zu

export BBPATH="${OMDIR}/build:${OMDIR}/oe:${OMDIR}/openembedded:${OMDIR}/openmoko-sar"

in build/conf/local.conf anhängen:

BBFILES := "${BBFILES} ${OMDIR}/openmoko-sar/packages/*/*.bb"

Und evt. noch als Bequemlichkeitsfeature: in Makefile einfügen:

.PHONY: %-image
%-image:
	( source ./setup-env ; cd build ; bitbake -c build $*-image )

Dann sollte man mit make openmoko-sar-devel-image das neue Image bauen können. Bonuspunkt: Durch die Benamung mit dem Präfix openmoko- wird das Image automatisch von make flash-qemu-local gefunden und berücksichtigt.