Openmoko build infrastructure questions

[Andy Green]

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

Somebody in the thread at some point said:

|> ---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?
|
| Again, what's the exact problem description here? Cross-compilation is not
| "wrong" at all, it works very well. By compiling in environments like
| Scratchbox or Qemu we give away a lot of flexibility and scalability.
| It will kill performance and the end result (as in the flashable image)
| does not differ at all. So, where would be the potential benefit?

The potential benefit is no more recipes or cross build workarounds.
./configure just does the right thing.  It has to be slower though, how
much I dunno.  Personally I like cross alright, but qemu "native" is a
valid solution too.

|> ---3 "Openmoko should use normal .deb or .rpm packages, instead of
|> ipkg/opkg"
|> This usually includes people saying we should use src rpms / debian
|> src files to build packages.
|
| That's actually two different questions and I can only comment on one:
|
| 3.1. What's the actual problem here rather than a desperate attempt to
| unify the desktop and the embedded world more than what's good for
| the embedded world? Is it that .ipk are less known than .deb? Is it
| the feature of the command line tools or the packaging system per se?

See the end for a rant on this.

| RPM? I have yet to see a version of RPM that is working at all (not
| considering performance) on an embedded system like the Neo. Until
| then we should not even talk about that as a viable option.

There's nothing wrong with RPM for this.  Official RPM builds against
sqlite libs now if you want, and I wrote a version for busybox that is
even lighter, using package headers stored in /var/lib/rpm to know what
is installed and its metadata.

And from my side -- nothing wrong with .deb either, RPM and .deb do the
same thing about as well.

| 3.2. I have no experience with building from source packages other than
| tarballs. Maybe someone else can comment on that.

Well it's a funny one to deal with, but the non-cross qemu method
actually allows them to do that with no hassle.

| Moblin as in patches and applications is a different story, we should
talk
| about that on openmoko-devel, however my first impression is we would
give up
| a lot of flexibility by locking people in to one environment. The
openness of
| Openmoko depends on a large part on the availability of OpenEmbedded.
Without
| OpenEmbedded it will be much harder for people to come up with own
| experiments based on the Neo hardware.
|
| I hope that clarifies some things and gets the discussion started, if
| necessary.

I want to say about that "flexibility of OE".  I am haunted by a sense
of failure and distress this last week or so.  Wolfgang said "build DM2
with bitbake, put it in git or somewhere else and start patching it.".
I can barely half-build the thing anyway, god help me pkgconfig, but I
studied the OM Wiki that talks about using bitbake, I didn't find any
examples to copy.  When I googled one and fiddled with it, the Fedora
package for bitbake just said something about demanding to set a CACHE
variable, I look in the config file and see a ton of crap I have no idea
about.  man bitbake shows me a shell prompt.  I look at what is in the
package, I find info stuff in /usr/share.  I read two whole pages about
how great bitbake is, nothing about CACHE.

$ grep CACHE /usr/share/doc/bitbake-1.8.8
$

Bah I have to try to cook the thing and its dependent libs by hand with
a shell script.

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.  I can and do use RPM for normal and
cross packaging -- actual packaging, not just using the packages -- just
fine, I don't think the issue is I am particularly inbred.

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.

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

iEYEARECAAYFAkgF9z4ACgkQOjLpvpq7dMr+KwCdFLMopE5ombRroSHN/mneURp/
EBMAn2eWQie+bGjoPX3nn8JNHrZEBYN6
=i85L
-----END PGP SIGNATURE-----