**** BEGIN LOGGING AT Wed May 11 02:59:58 2016
May 11 08:29:34 <hrw> https://github.com/bitkeeper-scm/bitkeeper - will we move again? ;d
May 11 08:33:29 * joshuagl wonders if there's a git import
May 11 08:33:42 <joshuagl> slight irony that it's hosted on Github too :-)
May 11 12:47:37 <AndersD> uuuu:q!
May 11 18:58:48 <hofstee> hi, I am wondering if there is a easy way to speed up the build process by reusing the host binaries for the next build (e.g. meta-toolchain and adding a bunch of ASSUME_PROVIDED)
May 11 18:59:48 <hofstee> has anyone ever tried something like that? is that feasible?
May 11 19:02:39 <rburton> hofstee: host binaries get reused automatically
May 11 19:02:40 <rburton> (via sstate)
May 11 19:04:09 <hofstee> rburton: yes, I am aware of that, but this is for a build server which start from scratch every time (for different MACHINES / releases)
May 11 19:07:41 <rburton> native binaries are shared
May 11 19:07:41 <rburton> ie foo-native is always the same, no matter what machine
May 11 19:07:49 <kergoth> you dont need to start from scratch, a single sstate dir can be shared just fine between machines, distros, yocto releases, etc
May 11 19:08:02 <kergoth> you won't always get 100% reuse, of course, but it's harmless to have a single pool
May 11 19:08:32 <hofstee> yeah, but what if recipes forget to add things to sstate?
May 11 19:08:39 <kergoth> that doesn't make sense
May 11 19:09:04 <kergoth> it's not up to the recipe to do it, the classes take care of it for all recipes
May 11 19:09:50 <hofstee> and there is autoconf and friends, which might do things differently depending on seeing a library or not. If those sstate information is not complete, bugs might go unnoticed by the tester.. right?
May 11 19:10:05 <rburton> only if you have broken recipes
May 11 19:10:19 <rburton> there's quite a lot of testing to make sure that recipes don't behave like that
May 11 19:10:56 <rburton> basically, sstate is great at re-use
May 11 19:11:04 <kergoth> there are test scripts and package qa to check for precisely that case, autodetected deps
May 11 19:11:19 <rburton> especially host stuff which is only rebuilt when your distro changes its release name
May 11 19:11:21 <kergoth> the issue with sstate is pretty much never about reusing when it shouldn't
May 11 19:11:37 <kergoth> it's that it ends up not reusing easily, but that's the safest route, the failure mode is rebuild from scratch, not use something wrong
May 11 19:12:15 <kergoth> there's really no reason to start from scratch unless you're doing a release build or something similar that really needs to be paranoid
May 11 19:12:21 <kergoth> IMO anyway
May 11 19:18:47 <hofstee> ok thanks, I will test some things with sstate a see if I can fool it... regarding the original question (to simply reuse the host binaries from a bitbaked toolchain)...
May 11 19:19:17 <Marex> khem: nice burst of gcc6 upgrades, looking forward to fixing all the nios2 bugs with it ;-)
May 11 19:20:21 <hofstee> would there be pitfalls (besides the obvious one, you won't notice if they got accidentally changed (but that is rarely done in my case)
May 11 19:21:01 <kergoth> hofstee: probably doable, but you'd definitely be on your own with it, and as you've said there's a certain amount of risk with it. at least using a yocto toolchain rather than a host you know tools like autoconf have the necessary patches, so that'd be less of a concern
May 11 19:21:26 <kergoth> at one point i had a little class that injected entries into assume_provided based on what it detected on the host, but only for specific ones where it seemed safe to do so
May 11 19:21:31 <kergoth> but with sstate i pretty much set that aside
May 11 19:25:30 <hofstee> kergoth: the idea I have is to feed the OE sdk output back in to the next build (for native tools), not the ones of the host, I could have been a bit clearer about that
May 11 19:25:36 * kergoth nods
May 11 19:26:02 <kergoth> no, i got that, saying that definitely avoids issues you'd hit if you did go based on host tools
May 11 19:26:37 <kergoth> so it does seem like a viable approach, though i question the benefits vs sstate, would be best testing them out and measuring that
May 11 19:34:39 <hofstee> is there a way to only use sstate for the native build, and always rebuild for the target? that would basically boil down to the same, with the additional benefit that native changes also gets noticed...
May 11 20:09:18 <khem> Marex: yeah, you can start even now 
May 11 20:27:10 <Marex> khem: whee
**** ENDING LOGGING AT Thu May 12 02:59:58 2016