Mickey,
let's attempt to find some kind of 'Openmoko consensus' out of this
discussion:
OpenEmbedded is a tool to build distributions. One step _before_ the
distribution. If Openmoko wants to come out with unique devices one
day, targeting for example a new (non-ARM) CPU, OpenEmbedded will give
us the flexibility to quickly target that environment.
Moblin/Ubuntu Mobile is not an alternative right now, despite signs of
support nobody from Intel stepped up in this thread to make a case for
their platform and build environment.
OpenEmbedded is not tied to a particular package format, opkg is just
Openmoko's current choice.
We have identified two major weaknesses in Openmoko's current use of
OpenEmbedded, details of which may be connected to weaknesses or
missing features in OpenEmbedded:
1. -dev packages
2. Poky SDK
Richard Purdie expects to contribute several improvements connected to
these areas over the next few months, Holger Freyther will merge some
of the meta-toolchain improvements from Poky into Openmoko.
Over the next 1-2 months, Openmoko will switch away from monotone and
start using git for the OpenEmbedded metadata.
Overall we expect that 1) OpenEmbedded gets stronger and 2) Openmoko
makes better use of OE features, so that hopefully soon the resulting
Openmoko distribution will be powerful enough to not require people to
step back into the OE world except if they want to make major changes
to the whole distribution. Internally, we can then isolate work on OE
better, while most people work with prebuilt toolchains, -dev
packages, etc.
Are we all more or less on the same page now? Mickey, what do you think?
Wolfgang
On Apr 17, 2008, at 11:43 PM, Richard Purdie wrote:
On Thu, 2008-04-17 at 16:00 +0100, Andy Green wrote:
But I am encouraged you know what I am moaning about, you have a plan
for it and you are getting paid to work on it. If Openmoko want to
use
this as the default that will be a big step towards looking and
acting
like a "normal distro". If I needed to build against X libraries,
there's no reason at all I have to build X myself. Someone built the
libs already and made the includes available... just install that and
go. I dunno what those -devs are for otherwise.
The -devs are for on device development and you can do that if the
device is up to the job resource and connectivity wise already (see
Poky's sdk images).
The packaged staging packages and the -dev packages have a lot of
overlap and some have suggested using -dev packages directly but it
isn't quite as simple as that, I won't bore you with the
technicalities,
its all in the OE list archives.
| cd /whereever/the/toolchain/rootfs/is/
| ar -x tslib-dev.ipk
| tar -xvzf data.tar.gz
|
| if you want to do a quick hack.
This is the kind of thing but John points out there are other
dependencies. And unless it is done through a package system,
it'll get
out of hand with forgetting to update something by the hack method
and
be in a mess. So I guess it waits on your work.
Agreed. I'm just trying to show this isn't difficult and not as far
off
as people think. Package dependencies in the toolchain work in Poky
now.
If it works in Poky, making it work in OM is pretty trivial, then it
just needs documenting.
| My point is that OE isn't deficient as such, there are solutions
there,
| the OE devs are improving them and we mainly need to make them
better
| known about. Throwing a build system away and starting from scratch
| seems wasteful when the problems are just ones of documentation and
| communication which can be solved on short timescales if people
focus on
| them.
It's a multifaceted question... anyway it seems no changes will
come in
the short and probably not the medium term.
Therefore whatever adaptations can be made to make the build process
more packaged and regular along the lines we talked about would be
mega
welcome.
It really depends who imports the changes into OM since thats the main
obstacle in some cases. I can see all of the things I've mentioned
happening relatively soon, say the next couple of months.
Cheers,
Richard
