Openmoko build infrastructure questions

[Richard Purdie]

On Wed, 2008-04-16 at 14:48 +0100, Andy Green wrote:
> |> It has to be slower though, how
> |> much I dunno.  Personally I like cross alright, but qemu "native" is a
> |> valid solution too.
> |
> | Sure, no one said that it's not a valid solution. It just has more
> drawbacks
> | than benefits.
> 
> It has one drawback, speed.  What are the other drawbacks?

Doing native builds mean you either do it under emulation or you do it
on real hardware. There are issues of speed and whether the emulation is
accurate. It also assumed you have emulation available. You do for ARM,
what if you switched to AVR processors?

In the embedded space, your target systems are by definition smaller
than your build ones and its useful for the build system to be able to
take advantage of this.

> Yeah I'll go RTFM.  What puts me off is some note on the OM wiki you
> have to change things to point to some magic URL run by Openmoko not
> Openembedded, then I know it will sit there buildroot style pulling a
> load of "latest" sources from all around.  Bleagh.

See the development environment vs. build system discussion. Don't
confuse the two!

> What I want to do is link against official tslib.  Can I download a
> tslib-devel package for that like I can in Fedora or Ubuntu?  I don't
> think so.

We've recently made some simple changes to meta-toolchain in poky so you
can take your standalong SDK and "ipkg install tslib-dev.ipk". We even
added a shell alias "opkg-target" to make this easy so you don't have to
remember all the right options. See:

http://svn.o-hand.com/view/poky/trunk/meta/packages/meta/meta-toolchain.bb?rev=4185&view=markup

The thing to keep in mind is this kind of padding (usability) is near
enough trivial to add, the hard work is getting the base system and
foundations there and we have this!

The bigger problem is identifying where the issues are and what needs
adding to help usability.

> No, it is quite a strong argument.  If we used .deb for example, any
> debian or Ubuntu or god help us linspire if they still use it developer
> can come and work with our stuff with zero friction.  Bam.  If it was
> RPM, far from stumbling around in the dark I would have been up and
> running at full power in five minutes.

So this isn't a package issue, its more about the underlying build
system? You want to build things the same way as debian does?

> Like I say I quite like cross as a philosophy, but I am experiencing the
> fear and pain that any non-OE developer thinking about contributing will
> get even worse than me, since I at least am comfortable with cross and
> packaging generally.  This is significant.

Contributing as an application developer or building their own images?

Someone OE literate can add a new recipe for a well written piece of
software easily. The end users shouldn't have to touch OE.

> What I do think to myself is: this is not an "embedded device".  This is
> a PC of a few years ago and the packageset complexity shows it.  And we
> barely got started with userspace packages we will offer.  Yet somehow
> we use an "embedded" chain whose natural output is a rootfs.  The
> package system is not comparable to .deb or RPM, I mention again the
> - -devel issue.

The output is a set of packages and images. The package format can be
tgz, ipk, deb or rpm.

What you probably want is a source deb but this makes no sense in the OE
context. What you do have is -dev packages which can work with an
external sdk.

> The mainstream distros spent many years tackling the "being a distro"
> side of things and ended up with two strong mature ways to do it that
> are more or less identical in functionality.  OE it seems to me spent a
> lot off effort "doing cross", which is a great achievement, and less on
> these thorny packaging issues.

Not at all, OE prides itself on its much granular and embedded oriented
packaging.

All the major distros are not "embedded" friendly, the don't support
granular packaging and any patches to do this would be rejected. They
have totally different priorities.

> Going on our devices inside will over time get more like PCs in
> complexity, storage and capability, not less (this is independent of how
> non-PC-like the form factors may sometimes be).  If we just said "screw
> it" and jumped on Ubuntu or Fedora native-compiled on Qemu, pain from
> that will only lessen over time, not increase.

Your patches to customise Fedora or Ubuntu for Openmoko's purposes will
be invasive and you will have the burden of maintaining them. Upstream
will also make changes without caring about your patchset.

Assuming you successfully made such a set of patches which is a massive
undertaking in itself, you'd then end up being unable to upgrade due to
the monumental effort in porting the patches. 

> So yes, if Intel can make a convincing story about effectively
> delivering Ubuntu Mobile / .deb-basis for us on ARM with or without
> without cross, and there are no nasty stings in the tail (like 1/10th
> compile speed :-) ), I think that would be a step in the right
> direction, not the wrong direction.

It appears they're starting from scratch on this and believe me, there
are many hurdles to cross.

> What about -devel packages so I can build against official tslib?  I can
> do this on a normal distro and we wouldn't need to suffer my ravings and
> horrified groans.

I have no idea why you don't have -dev packages but as Holger pointed
out, they exist for Angstrom, I know they exist for Poky and I have no
idea why they aren't available for OM but its not OE's fault ;-).

Cheers,

Richard