Faster build process than openmoko-devel-image?
Visti Andresen
talpa at galnet.dk
Fri Jul 20 10:04:49 CEST 2007
On Fri, 20 Jul 2007 02:19:22 -0500
Jeff Rush <jeff at taupro.com> wrote:
> 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?
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:
>
> 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
More information about the openmoko-devel
mailing list