1681 2011-10-14 15:22:31 +0000 Allow meta-toolchain to be used instead of building tools dynamically 2012-08-13 13:24:58 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto unspecified x86 Multiple RESOLVED WONTFIX Low enhancement Future 1 gary richard.purdie bjst david.nystrom mail poky.bs.watcher poky.watcher sgw --- --- --- oldest_to_newest 16886 0 gary 2011-10-14 15:22:31 +0000 Create a general purpose recipe which can be used to allow the use of a Poky/Yocto built toolchain (meta-toolchain) instead of building one dynamically. Similar to the CSL recipe http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb It should not be necessary for "Joe Average" to have to figure out how to do this, rather a simple choice in local.conf should suffice. The "magic" currently required to make this work is beyond most users of Poky/Yocto. 18692 1 david.nystrom 2012-02-22 01:09:22 +0000 Gary, Saul, Richard We are currently in a sprint needing this feature. Whats the status of the fix ? If there is nothing done on this, and if you are OK with it, assign this bug to me. Would it be possible for us to have a branch in poky.git || poky-contrib.git to make it easier for us to work upstream (review and e.t.c.) ? 18695 2 richard.purdie 2012-02-22 03:17:25 +0000 The mechanism we're encouraging for this is to use binaries from the sstate cache. If you are worried about the checksums changing and want to really fix it down, you could create a custom sstate cache policy which fixed the toolchain component checksums, like an extended version of meta/lib/oe/sstatesig.py. We did once have external toolchain support for our own toolchains like you describe but it was a massive pain to maintain and use, duplicating a lot of the sstate like code to capture the pre built packages (needing to handle all of .deb, .ipk and .rpm) as well as the pkgdata output from do_package. I cannot advise more strongly about not wanting to do this again. The external toolchain recipes will of course work perfectly well if you are happy for the system to re-package things each time like external-csl does. As for poky-contrib access, that is no problem at all. Please send Michael Halsted an ssh key, cc me and we can get people access. 18697 3 david.nystrom 2012-02-22 04:48:14 +0000 (In reply to comment #2) > The mechanism we're encouraging for this is to use binaries from the sstate > cache. > > If you are worried about the checksums changing and want to really fix it down, > you could create a custom sstate cache policy which fixed the toolchain > component checksums, like an extended version of meta/lib/oe/sstatesig.py. > > We did once have external toolchain support for our own toolchains like you > describe but it was a massive pain to maintain and use, duplicating a lot of > the sstate like code to capture the pre built packages (needing to handle all > of .deb, .ipk and .rpm) as well as the pkgdata output from do_package. I cannot > advise more strongly about not wanting to do this again. My main reason to not use the sstate is that I don't understand it entirely(yet), which of course if not a valid reason. Is there any additional information (except the code) that contains some more details of what the sstate cache really does/contains ? Why was the normal package format(ipk/deb/rpm) not chosen as a binary build cache ? I understand that this would probably force a user to use the same package format as selected by the pre-built. I'll read up on the sstate and get back to you. 18710 4 richard.purdie 2012-02-22 15:07:08 +0000 Take a look at http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#shared-state-cache 23958 5 richard.purdie 2012-08-13 13:24:58 +0000 sstate exists for people wanting to use standalone toolchains built by OE. Adding the extra pieces for this to meta-toolchain was attempted in the past, its ulgy end error prone and sstate provides a much neater solution which already exists. This is therefore the one we're going to recommend and support.