Openmoko build infrastructure questions
rpurdie at rpsys.net
Wed Apr 16 16:09:05 CEST 2008
On Wed, 2008-04-16 at 13:24 +0100, Michael 'Mickey' Lauer wrote:
> I have been requested to comment on our choice of build tools, specifically
> OpenEmbedded. Unfortunately most of the statements people have approached
> us with are not based on technical problems, but rather a vague sense
> of uncertainty and doubt, which it is hard to argument against.
> Anyway, let us take this opportunity to clean up some things and reply based
> on facts and technical arguments.
I'll also reply to some of these questions since sometimes a different
perspective can help...
> Now the first bunch of questions:
> >---1 "The openwrt build system is much easier to use than OpenEmbedded"
> >Can Openmoko switch to the openwrt build system?
"easier to use" is a very subjective and it depends a lot on your
background. If you're used to makefiles you'd love buildroot but if you
don't understand makefiles its more of a nightmare.
OpenEmbedded was written to allow various separate build systems and
projects pool their development efforts and expertise into one place. To
do this it has to have good abstraction and distinction between
"machine", "distribution", "recipe" and other metadata.
OpenEmbedded was written from scratch to do this and its safe to day
that nothing else in the market has this capability. The downside is
this brings in a certain level of complexity rather than a single
purpose build system.
Lets say a Openmoko suddenly decide to build an AVR based phone. How
easy is it to add that to the openwrt build system vs. OE? How easy is
it to try out a different libc? You find running "magicspeedup" on all
the system binaries make the system 400% faster, how easy can you add
that to OE to do automatically compared to build system X?
Openmoko leaped ahead at the start in a number of ways by benefiting
from the hard work already done in OE to make working embedded images.
This isn't something you realise until you try to move to some other
system and find all the work you took advantage of in OE has to be done
from scratch elsewhere.
> >---2 "building with a cross-compiler is wrong, builds should be done
> >natively in an emulated (qemu) arm environment"
> >Can Openmoko switch to compiling arm binaries 'natively' in a qemu
> >environment, like Ubuntu Mobile?
I think its important to differentiate between a development environment
and a build system here.
OpenEmbedded is a build system and integration tool through and through.
Yes, you can use it as a development environment but it wasn't designed
for that. Some day it may be directly usable as a development
environment and this is something I personally have worked on and will
continue to do so but at present its not end user ready for that IMO.
So what are the options for a development environment? I'd strongly
suggest people look at Poky's IDE plugin for Anjuta, its standalone
toolchain and SDK and/or its native SDK images. This gives you the qemu
environment if you want it with either cross compiling or native
compiling depending on your preference. OE can do all this, Openmoko are
just not taking advantage of it.
> >---3 "Openmoko should use normal .deb or .rpm packages, instead of
> >This usually includes people saying we should use src rpms / debian
> >src files to build packages.
OE can use which ever package format you want. .ipk and .deb both work
well. There is rpm code there but it doesn't work, mainly due to
limitations in the rpm system. Point me at other build systems where
there is package abstraction this good? Using OE gives you the option of
changing very easily.
> 3.2. I have no experience with building from source packages other than
> tarballs. Maybe someone else can comment on that.
This comes down to the choice of build system. If you want debian source
packages, why not just use debian?
OE could create a source package, it could actually consist of a copy of
the .bb recipe with the sources. Does that make the distinction clear?
> >---4 "Merge the Openmoko distribution into Moblin"
Mickey covered this and I know little about Moblin.
I also want to add a personal observation about Openmoko. From my
perspective there have been a lot of sharp changes in direction, often
due to people's personal views on things and I think this lack of
dedication to decisions has cost the project badly already.
I can believe a number of people don't like OE and want to change. That
change will mean massive upheaval and everyone having to learn some new
system and probably cost say 6 months 'downtime'. I personally believe
this is purely a case of "grass is greener on the other side" and in
reality there will always be someone who dislikes the system and there
will always be issues with whichever system is chosen.
If instead effort is concentrated on fixing the bad things about OE, you
can achieve a heck of a lot in 6 months. OpenMoko has not really put
that much effort into actually improving the OE infrastructure so far
but it does have people who could if they were able to dedicate the time
for that and knew what people wanted addressing.
I'll also add that Poky is light years ahead with its SDK and IDE
environments and there is a quick fix there for some issues ;-).
More information about the distro-devel