Neat compile/run cycle with git and OpenEmbedded

No matter how much careful we are when writing code, whatever changes we are making to a piece of software we must test them before production, even Donald Knuth once said: Beware of bugs in the above code; I have only proved it correct, not tried it. :).

Moreover, if the software we are working on is targeting an embedded system and needs cross-compilation and depends on other software, then testing can be more tedious: we have to prepare patches/archives and instruct the target SDK to pick our latest code, or we could code directly in the SDK working tree, but that would not be very clean. If you use git and OpenEmbedded there is a very neat way to build directly from our own working directory on the filesystem.

By developing with git from the start, your changes are ready to be sent upstream as soon as they are proven to be OK.

Git cloning from filesystem

I am not going to repeat how nice, sleek and whatnot git is, just let me show you again how flexible it is: you can easily “re-clone” from a git clone on the filesystem, no need to have any servers around:

$ cd /tmp
$ git clone file:///home/ao2/Proj/EZX/OE/framework

See? By only using the file:// URI scheme we fetch from a git (working) directory: a git directory is a valid git repository, there's some beauty in this regularity.

Fetching the latest code from our git working dir with OpenEmbedded

OpenEmbedded uses the bitbake task executor, .bb files (called recipes) are used to describe bitbake tasks, they are generally used to define packages for distributing some software, and the source code of the software can be fetched in many different ways; in this case we are editing a recipe which uses the git fetcher, let's take a look at the original recipes/freesmartphone/

DESCRIPTION = "The reference implementation of the framework APIs"
AUTHOR = "FreeSmartphone.Org Development Team"
SECTION = "console/network"
DEPENDS = "python-cython-native python-pyrex-native"
SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
PV = "${SRCPV}"
PR = "r3"
PE = "1"

inherit distutils update-rc.d python-dir

INITSCRIPT_NAME = "frameworkd"
INITSCRIPT_PARAMS = "defaults 29"

SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
           file://frameworkd \
           file://frameworkd.conf \
SRC_URI_append_shr = "file://oeventsd-use-opimd-signals.patch;patch=1"

S = "${WORKDIR}/git"

we can change the path in SRC_URI to a directory on the filesystem, and change the protocol to file so that git uses our working copy to fetch the code for the package, we can also specify our development branch here. Note that we still have to use the git:// scheme, because that's what tells bitbake which fetcher to use.

diff --git a/recipes/freesmartphone/ b/recipes/freesmartphone/
index dac7fe9..ddae81d 100644
--- a/recipes/freesmartphone/
+++ b/recipes/freesmartphone/
@@ -4,9 +4,9 @@ AUTHOR = "FreeSmartphone.Org Development Team"
 SECTION = "console/network"
 DEPENDS = "python-cython-native python-pyrex-native"
-SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
 PV = "${SRCPV}"
-PR = "r3"
+PR = "r4"
 PE = "1"

 inherit distutils update-rc.d python-dir
@@ -14,7 +14,7 @@ inherit distutils update-rc.d python-dir
 INITSCRIPT_NAME = "frameworkd"
 INITSCRIPT_PARAMS = "defaults 29"

-SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
+SRC_URI = "git:///home/ao2/Proj/EZX/OE/framework;protocol=file;branch=freescale_neptune \
            file://frameworkd \
            file://frameworkd.conf \

Now we are set, we can build packages as usual and test our local changes on the target system:

$ bitbake -c clean recipes/freesmartphone/
$ bitbake recipes/freesmartphone/

CommentsSyndicate content

Didn't know about git cloning

Daniel Ribeiro's picture

Didn't know about git cloning from filesystem. Very helpful, thanks! :)

Really nice reading, made me

sabrod's picture

Really nice reading, made me digerate the OE's getting started and de-stress a little, hehe...
Thanks a lot

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account associated with the e-mail address you provide, it will be used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Enter the code without spaces.