[OE-core] Using meta-toolchain output as prebuilt toolchains
denis at denix.org
Thu Mar 31 21:36:31 CEST 2011
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:
> 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.
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.
> > 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...
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
More information about the Openembedded-core