[OE-core] Using meta-toolchain output as prebuilt toolchains

[Denys Dmytriyenko]

On Mon, Mar 28, 2011 at 08:25:08PM +0100, Richard Purdie wrote:
> On Sun, 2011-03-27 at 13:44 +0200, 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.
> 
> In theory, something like that recipe should also work against the
> output of OECore's "bitbake meta-toolchain" output.
> 
> I would however suggest looking at this for inspiration:
> http://git.openembedded.net/cgit.cgi/openembedded-core/tree/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb
> 
> as the:
> 
> GLIBC_INTERNAL_USE_BINARY_LOCALE ?= "compile"
> inherit libc-package
> 
> might save duplicating half the libc packaging code. You also get the
> cross locale generation as an added bonus so no qemu! :)
> 
> There is a poky-external-toolchain recipe there too but its broken.
> Everything that did, sstate now does better so that should really be
> removed. Its advantage was not having to repackage the libc locales but
> it was so much hacky code to implement, wasn't multiple package manager
> safe and sstate replaces it much more neatly. If anyone does want to use
> external toolchains like that, I'd suggest the csl example above as the
> way to do it now.

Richard,

Those 2 lines indeed make the recipe much smaller and easier to read! I wish 
we had that support in OE when I worked on the original CSL and Angstrom 
external toolchain recipes... Although, they were inspired by and based on the 
old Poky recipes, but evolved quite a lot since then.

Anyway, I'll try to get some time to port the external recipes to oe-core 
using this new libc-package class. Thanks.

-- 
Denys


> > 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.
> 
> sstate mirrors are the way I think things will work well in the future.
> They're being used heavily by the yocto development team internally,
> support in Yocto 1.0 is looking good for sstate and hence its looking
> good for OE-Core.
> 
> To use it simply share the sstate-cache directory over http or nfs or
> whatever and then set:
> 
> SSTATE_MIRRORS ?= "\
> file://.* http://someserver.tld/share/sstate/ \n \
> file://.* file:///some/local/dir/sstate/"
> 
> to point at wherever the files are...
> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core