[OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig

[Rich Persaud]

On Feb 21, 2019, at 18:51, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> 
> Multiconfig is meant to support this workflow. Unfortunately there are
> open bugs and people haven't the time to work on it so its stalled.
> That said, the key pieces are already there.
> 
> A picture is worth a thousand words. I thought a demo might interest
> people and "prove" this can work.
> 
> To make it work you need four patches:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b896b2238c100d486e7c43992b49001150749d04
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=e5ef6b008e85f42b5e4ffd72fae7036dd68b2ea5
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=5d2bd43d14315ef3212e0d09a16446bd74305a2f
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=abdb83576b699448b76293294809aaa04b8e853b
> 
> The first two are fixes from Alejandro which haven't merged as they're
> not right. The third patch was me hitting the fixes and bitbake to make
> the demo work. That proves they're not right and hints at where we have
> some problems in bitbake too. We can get those issues sorted fairly
> easily and I'm going to block 2.7 M3 on them.
> 
> The final patch is the interesting one.
> 
> It adds a layer, meta-multiconfig-example layer with a README about how
> to configure it. Basically you create two multiconfig configurations,
> "musl" and "tiny".
> 
> The demo is to run "bitbake core-image-full-cmdline".
> 
> The result is a core-image-full-cmdline image with a tiny qemux86 image
> and a musl based qemux86-64 image installed into /var/lib/machines/
> 
> The way it does this is creative, having a recipe called image-packer
> which creates virtclass variants of itself which depend on the
> appropriate multiconfig. It pulls in the images and creates a package
> containing them which the bbappend to core-image-full-cmdline can then
> install. It'd be very easy to turn this into a list driven piece of
> code rather than the two values currently listed.
> 
> Its late here, some of the above code is horrible. I have rushed this
> but hopefully it shows this is possible! :)
> 
> I've love to turn this into an oe-selftest, that is my ultimate 
> intention for this code.
> 
> As things stand today you can't query one multiconfig from another. As
> this demo shows, that doesn't need to stop you making interesting
> things though. We will do something with such querying eventually to
> make things easier but until then, much is still possible.

For search engines: the multiconfig demo from this thread is now is an oe-selftest:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/multiconfig.py

Are there other public examples of combining artifacts from different machines into a single image via multiconfig?  We can include them in a doc update for Dunfell.  A list of use cases could motivate more people to try multiconfig.

For developer workflows, multiconfig can accelerate multi-image builds (more parallelism) but slow single-package builds (more recipe parsing).  As a workaround, BBMULTICONFIG="" restores the speed of building a target for a single MACHINE+DISTRO config.

Is there a better way to disable multiconfig for a single bitbake invocation?  Bitbake currently requires a MACHINE to be specified for multiconfig builds.  It also accepts non-multiconfig target names, even when BBMULTICONFIG is defined.  From a usability point of view, this CLI syntax could distinguish the two workflows:

  standard build:  MACHINE=foo bitbake singleconfig-image  
  multiconfig build:  bitbake mc::multiconfig-image

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200210/3944195b/attachment.html>