Openmoko build infrastructure questions

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> The potential benefit is no more recipes or cross build workarounds.
|> ./configure just does the right thing.
|
| If ./configure bails out on cross-compiling, then it is broken -- period.
| Autotools has been written to support multiple platforms, if it does
not, we
| need to fix it. OpenEmbedded has already achieved a lot in teaching
upstream
| authors about hardcoded assumptions, abusing autotools, etc. OE will
continue
| its fight to improve the build quality.

I marvel that OE is able to crosscompile perl and python, I tried that
and their build process is inherently anti-cross, demanding to run the
compiler/interpreter it just cross-compiled as part of the build action.

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

|> I want to say about that "flexibility of OE".  I am haunted by a sense
|> of failure and distress this last week or so.
|
| Sounds like you really should have checked upstream documentation. Try
| http://openembedded.org -> Getting Started Instructions

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.

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.

|> Now one can say ha you clueless N00b any fule know you have to blah
|> blah, but I say to myself, if this was RPM or .deb based I would have
|> googled out an answer and gone on.
|
| Uhm, so your argument boils down to just because more people are using
it... I
| don't find that a particular convincing one.

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.

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.

| So if it was you to decide, you would ditch OE and use Ubuntu Mobile
or RedHat
| or Debian on the phone?

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 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.

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.

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.

|> The other things that bother me about OE are the lack of SRPM type
|> source capture -- critical feature for license compliance -- and the
|> epileptic-fit inducing problems with -devel type include / libs
|> packaging, being able to pass around and host-install cross-devel
|> packages to cross compile other packages against easily.  If I use RPM
|> or .deb I get grown-up support for this.
|
| Dunno about grown-up support, but OE can distribute sources and
patches fine.

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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgGA4YACgkQOjLpvpq7dMovkgCeMfXwEzY79vbGrLC75zr/dfs9
hmEAniwfmhIfF8bNQhX2xNrrA8pa50XB
=hoVY
-----END PGP SIGNATURE-----