Wednesday, September 1, 2010

working with a local git tree and OpenEmbedded

OpenEmbedded works pretty well as a system-level build system but sometimes one needs to develop something locally (for example, a whole application or a set of changes) before committing to a tree that OpenEmedded pulls from.   OpenEmbedded won't really pull local files, and it's uncomfortable to not have revision control either way.

I use a local git tree to achieve this the work flow, which someone else might find useful.  I originally came across this approach here but want to elaborate a bit.

Setup

First, create a git tree for your project. For example:

$ mkdir myapp.git
$ cd myapp.git
$ git init --bare


This sets up the git management stuff that OpenEmbedded will use. Now clone it:

$ cd ..
$ git clone myapp.git myapp
$ cd myapp


...and either start developing there or grab your code from somewhere else.  For example, we can add a file (or several) and push to a new branch, "master".

$ cp /path/to/something/main.c ./
$ git add main.c
$ git commit -a -m "initial commit"

$ git push origin master

Edit (or create) an OpenEmbedded recipe for your app and tell it to fetch from the local git. You need the full path to 'myapp.git', for example '/home/andrey/myapp.git'. In the recipe this looks like:

SRC_URI = "git:///home/andrey/myapp.git;protocol=file;branch=master"


Note the three "/" after "git:".

Change / Build / Test

Now, the workflow is:

  1. make some changes to the source code
  2. commit and push:

    $ git commit -a -m "my change"
    $ git push origin master

  3. in OpenEmbedded, clean and rebuild:

    $ bitbake -c distclean myapp && bitbake myapp

  4. deploy and test your app
  5. repeat as needed

When you're happy with a set of changes, commit them to some upstream (or otherwise not local) tree or send a patch to someone.  The advantage is that you are able to work locally and you have revision control for all of your changes, no matter how minor.  In addition, your application builds within OpenEmebdded and has access to dependencies that it may need.  You do have to suffer some time waiting for bitbake to do its thing, but that can be quite fast for small applications or libraries.  You can then switch the "SRC_URI" for your recipe to pull from your remote repository and switch back to the local one when you need to make and test some more quick changes.

1 comment:

Unknown said...

After following the steps here, I got an error saying "Not a valid object name 1" during do_fetch. Apparently you still need

SRCREV_pn-${PN} = "${AUTOREV}"

in the recipe for it to pull the latest revision.