Faster build process than openmoko-devel-image?

Visti Andresen talpa at
Fri Jul 20 10:04:49 CEST 2007

On Fri, 20 Jul 2007 02:19:22 -0500
Jeff Rush <jeff at> wrote:

> Visti Andresen wrote:
> > On Thu, 19 Jul 2007 05:44:54 -0500
> > Jeff Rush <jeff at> wrote:
> > 
> >> Alright, I've finally figured out how to add new packages to builds, and am
> >> starting to develop.  However, I'm finding the turnaround rather slow.  I'm
> >> using the commands:
> >>
> >>  (make changes)
> >>  # make openmoko-devel-image
> >>  # make flash-qemu-local
> >>  # make run-qemu
> Hmm, apparently I mispoke when I said I figured out how to add packages to
> builds.  When I added the following line to my build/conf/local.conf:
> and did:
>  # make openmoko-devel-image
>  # make flash-qemu-local
>  # make run-qemu
> I indeed got Python onto the device.  Yay!  But when I went one step further
> and changed that one line to:
>   DISTRO_EXTRA_RDEPENDS = "python python-dbus python-pygtk2"
> and rebuilt things, no DBUS nor PyGTK2 stuff is present in the root
> filesystem.  Drat!  Apparently this stuff is more subtle than I thought.
> I'd like to see on the wiki a simple recipe for adding and removing an
> existing package from the flash image.  And another one for rebuilding the
> kernel with different menuconfig options.  Those three would go far in getting
> one started.
> > I don't know... 
> > But you could also just build the specific ipk package and scp it to the
> > emulator and install it using 'ipkg install file'
> Thanks for this tip -- I've not worked with "ipkg" before and didn't realize
> this was an option.  I come from the world of Red Hat RPMs and Gentoo ebuilds.
>  I tried to look into an .ipk file, as the site said they are just tar.gz
> files, but the ones in the OpenMoko image apparently are not, as no variation
>  of tar would read it, nor did the "file" command identify it.
> > And for the small programs I normally create, I build them so they also can
> > be run without installation from the build directory.
> > This way I should be able to do:
> > 1. qemu: ssh-fuse mount the build directory
> > 2. pc: make changes
> > 3. pc: build (using make or other tool)
> > 4. qemu: execute new exe from fuse mount and "goto 2."
> You say "should be able to do" - are you not currently using this approach to
> experiment with development yet?
No I haven't tried it yet for OpenMoko, I'm still studying bitbake and
relearning GTK (I normally use wxWidgets for gui development as it is
more crossplatform that gtk)

> I hadn't thought of using ssh-fuse but
> rather the NFS support already on the device -- I'm having to rework my IP
> addresses though because I already use the set built into the flash image on
> my LAN.
> > I'm very new to this entire bitbake ting.
> Me too, including quilt and OpenEmbedded.  I spent yesterday reading
> everything I could find on it.  I think I understand BitBake now, but haven't
> found much explanatory material on the many different 'variables' within the
> .bb files that have meaning to the BitBake recipes.  For example, the fine
> distinctions of when to use each of these is giving me heartburn:
> > Seems that I wouldn't want to use bitbake for day to day development 
> > as i would have to make a change, then commit it and the do a bitbake?
> > At least if I don't want to maintain two recipes 
> I'm trying to figure this out too -- the best way to do actual development of
> new code.  It seemed using 'quilt' and 'bitbake' and 'MokoMakefile' was the
> preferred way, but it has a certain overhead to it when you're rapidly
> iterating inside your own work.  Now your suggestion of just build an ipkg and
> manually install it is another way, with less overhead.  And of course NFS
> mounting the desktop from within the device, and doing ordinary
> cross-compile/links on your desktop and running the result within the device
> is the least overhead way, albeit less managed.
> > So for development I use another build system?
> > and I instruct bitbake to use this system when compiling
> So it seems.
> -Jeff

More information about the openmoko-devel mailing list