Faster build process than openmoko-devel-image?

[Jeff Rush]

Visti Andresen wrote:
> On Thu, 19 Jul 2007 05:44:54 -0500
> Jeff Rush <jeff at taupro.com> 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:

  DISTRO_EXTRA_RDEPENDS = "python"

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?  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:

MACHINE_EXTRA_RDEPENDS =
DISTRO_EXTRA_RDEPENDS =
BOOTSTRAP_EXTRA_RDEPENDS =
DISTRO_FEATURES =


> 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