Openmoko build / Rebuild vs -dev

[Wolfgang Spraul]

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