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