[bitbake-devel] Should multiconfig save build time?

[Richard Purdie]

On Fri, 2019-06-28 at 13:31 -0400, Alan Kozlay wrote:
> We have need to generate 6 slighly different images, with different
> dedicated applications and use cases, but they're all destined for
> the same hardware.
> We have multiconfig set to build these 6 variants.  Clearly, they'll
> all share a majority of underlying packages.
> While the bitbake initialization takes a long time (with
> multiconfig), we were under the impression that it could save time
> during the actual build process because it could have the potential
> to reuse packages already built from mc A for mc B if the inputs to
> the recipes are unchanged (if same xxx_FEATURES, same arch, etc.).
> 
> This was a guess on our part since we initially didn't assign
> different tmp directories for each conf.  So, the <WORKDIR> didn't
> change between mc builds.  That actually was causing some issues
> until we realized that separate tmp dirs was recommended for them.
> Since they all now have separate tmp dirs, they clearly are not going
> to share work dirs, so, now we're questioning our original assumption
> about any build-time speed benefit.
> 
> So, is mc expected to be any faster than, say, 6 separate invocations
> of non-mc bitbake whilst switching out the local.conf between them? 

Ultimately, yes, it would be expected to be faster.

With the code as it stands today, no, it won't be. Its a known open
issue:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10682

What would be faster is to build one of the configs initially which
will populate the sstate cache, then build the other 5 together in one
multiconfig.

We obviously want to get that issue fixed ultimately but its not an
easy thing to do due to the way our codebase works.

Cheers,

Richard