Openmoko build / Rebuild vs -dev
wolfgang at openmoko.com
Fri Apr 18 04:36:47 CEST 2008
let's attempt to find some kind of 'Openmoko consensus' out of this
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
Are we all more or less on the same page now? Mickey, what do you think?
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
>> this as the default that will be a big step towards looking and
>> 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
> 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
>> 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
> as people think. Package dependencies in the toolchain work in Poky
> 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
>> | the OE devs are improving them and we mainly need to make them
>> | 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
> 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.
More information about the distro-devel