<div dir="ltr"><div dir="ltr">All,<input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"1","compose-window":{"secure":false}}"><div><br></div><div>In regards to our original June 28th post:</div><div><br></div><div>We're looking for things we can do to improve the multiconfig build time.</div><div><br></div><div>Even on our build servers it still takes a long time.</div><div>For instance, our build servers each have 64 core, 128G RAM with 4 NVMe SSD HDs in a striped raid (<i>all configured with bells and whistles to make it super fast</i>).</div><div>A full fresh build on one of those servers still takes 6 hours.</div><div><br></div><div>I need to also clarify that we do indeed define different DISTRO_FEATURES between multiconfigs, so multiconfig is necessary.</div><div><br></div><div>(1) We're attempting to use the ccache (via ccache.bbclass), but it's causing some build errors that we're investigating.</div><div>(2) Can we at least set the root native work directory to be the same for all multiconfigs?</div><div><ul><li>Would each multiconfig honor the previously built native tools?</li><li>Or, would it just rebuild them, anyway?</li><li>Is this safe or tested or supported?</li></ul>(3) We're considering a network shared sstate-cache. But it's not entirely clear if a multiconfig build is benefited by the sstate-cache directory.</div><div><ul><li>Under what circumstances does a multiconfig leverage sstate-cache when building for another multiconfig?<br></li><li>What if the recipe would be affected by a change in DISTRO_FEATURES between multiconfigs?<br></li><li>Are native packages included in the sstate-cache or just target packages?<br></li></ul></div><div>We welcome all thoughts and ideas.</div><div><br></div><div>-Alan</div></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Sun, Jun 30, 2019 at 5:38 PM Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2019-06-28 at 13:31 -0400, Alan Kozlay wrote:<br>
> We have need to generate 6 slighly different images, with different<br>
> dedicated applications and use cases, but they're all destined for<br>
> the same hardware.<br>
> We have multiconfig set to build these 6 variants. Clearly, they'll<br>
> all share a majority of underlying packages.<br>
> While the bitbake initialization takes a long time (with<br>
> multiconfig), we were under the impression that it could save time<br>
> during the actual build process because it could have the potential<br>
> to reuse packages already built from mc A for mc B if the inputs to<br>
> the recipes are unchanged (if same xxx_FEATURES, same arch, etc.).<br>
> <br>
> This was a guess on our part since we initially didn't assign<br>
> different tmp directories for each conf. So, the <WORKDIR> didn't<br>
> change between mc builds. That actually was causing some issues<br>
> until we realized that separate tmp dirs was recommended for them.<br>
> Since they all now have separate tmp dirs, they clearly are not going<br>
> to share work dirs, so, now we're questioning our original assumption<br>
> about any build-time speed benefit.<br>
> <br>
> So, is mc expected to be any faster than, say, 6 separate invocations<br>
> of non-mc bitbake whilst switching out the local.conf between them? <br>
<br>
Ultimately, yes, it would be expected to be faster.<br>
<br>
With the code as it stands today, no, it won't be. Its a known open<br>
issue:<br>
<br>
<a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=10682" rel="noreferrer" target="_blank">https://bugzilla.yoctoproject.org/show_bug.cgi?id=10682</a><br>
<br>
What would be faster is to build one of the configs initially which<br>
will populate the sstate cache, then build the other 5 together in one<br>
multiconfig.<br>
<br>
We obviously want to get that issue fixed ultimately but its not an<br>
easy thing to do due to the way our codebase works.<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span><div><div dir="ltr"><div><div>Alan Kozlay<br></div><div dir="ltr">VES Solutions, LLC<br><span>Alan Kozlay <alan.kozlay@ves.solutions></span><div>DESK 443-595-7734<br></div><div>CELL 443-752-0323</div></div></div></div></div></span></div></div></div></div></div>