Re: Using meta-toolchain output as prebuilt toolchains

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2011-03-29 at 05:32 -0600, Gary Thomas wrote:
> On 03/28/2011 12:58 PM, Tom Rini wrote:
> > On 03/27/2011 04:44 AM, Koen Kooi wrote:
> >> What is the preferred way of 'importing' prebuilt toolchains into OE-core? In oe.dev I can use this: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/meta/external-toolchain-angstrom.bb to 'import' an angstrom toolchain built with 'bitbake meta-toolchain', but I'm not sure how to do that in OE-core.
> >>
> >> My actual use case is actually 2 use-cases:
> >>
> >> 1) Hand people a prebuilt angstrom toolchain and migrate them to OE while keeping the toolchain
> >> 2) "Get started in 10 minutes" type of thing, I suspect an sstate mirror might be better.
> >>
> >> So any suggestions for #2 as well?
> >
> > sstate is the best way to catch #2 and I know in general there's "look
> > at this URI for the file you want" bits.  I haven't yet started kicking
> > the tires on sstate as hard as I have for packaged-staging however.
> 
> This is the approach I've been working on to pass on to my customers.  The
> idea that I can give them a packaged bundle which includes prebuilt tools
> is far more attractive than a simple poky (or oe-core plus layers) tree
> which involves many hours of building to produce a simple image.
> 
> Hopefully, the sstate method will become more stable over time.  The problem
> I've had with it recently is that there are so many variables which are used
> to decide if the sstate data is valid (see Richard's description on how this
> works) that if the smallest thing changes, the whole lot becomes useless :-(
> so it's really only valid for a [fairly] static repository.

It depends what changes your customers expect to make and whether with
those changes you consider the prebuilt data still to be valid. I agree
that the defaults do tend towards detecting even small changes. I think
over time we'll get a better feel for the things that should/shouldn't
be included in there. It is almost totally customisable and what we're
missing now is some good "policy" type data.

Cheers,

Richard