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 > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
