On Fri, 2014-12-19 at 13:11 +0100, Enrico Scholz wrote: > Richard Purdie <[email protected]> writes: > > to the point of not being a currently well supported use case and the > > classes would probably need to be refactored to allow such things to > > be well supported. These changes do bring significant benefit > > Does some lowered i/o really provide such a benefit? With the new > system you are bypassing the excellent staging system (which would > detect e g ".config" or "System.map" file conflicts). Afais, it breaks > with "rm_work" too (I guess, kernel:fetch stamp is removed when kernel > build finishes and packages which inherit "kernelsrc" fetch the kernel > sources (without .config and System.map) again).
In summary, basically, yes. The kernel source is huge and we were compressing/decompressing it in several places on the critical path. People were struggling to develop kernels using the system due to the overhead. Whilst this approach does bypass some parts of the system, I do believe the benefits are worth it. We're talking about making the kernel build time about three times faster iirc, and reducing its sstate footprint significantly. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
