**** BEGIN LOGGING AT Thu Jun 27 02:59:57 2019
**** BEGIN LOGGING AT Thu Jun 27 11:55:06 2019
Jun 27 13:43:06 <laplante> RP: I'm interested in implementing optimization for multiconfig builds, i.e. so that common parts of multiconfig builds are not built twice. Any pointers on where I might start looking? I haven't dug too deep into the code yet, but I imagine changes will be necessary in RunQueueData::prepare.
Jun 27 14:24:25 <RP> laplante: fixing that basically means rewriting runqueue
Jun 27 14:24:44 <RP> laplante: its not an easy one to fix. I'm planning to look at it if I can stop having to fix autobuilder issues
Jun 27 14:25:10 <RP> laplante: Its one of the few tasks that will probably have to be done by people with knowledge of runqueue and sstate :/
Jun 27 14:25:51 <laplante> RP: ah ok :/. If you need help testing it let me know - we have several use cases in mind
Jun 27 14:27:21 <RP> laplante: part of the problem is we have no unittesting of runqueue so it will be a pain to know if we've broken anything
Jun 27 14:29:44 <laplante> RP: I see. This may be a naive question, but have you ever considered using a graph library (such as NetworkX) to implement the dependency resolution stuff?
Jun 27 14:32:30 <RP> laplante: no, that isn't where our problems are
Jun 27 14:32:47 <laplante> RP: I know, it was more a general question
Jun 27 14:33:51 <RP> laplante: most didn't exist when we started bitbake
Jun 27 14:46:41 <RP> laplante: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10682 is the bg btw
Jun 27 19:25:11 <rburton> using a graph library would be nice though, the more code that bitbake doesn't have to reimplement the better imho
**** ENDING LOGGING AT Fri Jun 28 02:59:57 2019