Re: [poky] [PATCH 2/4] conf/fragments: add fragments for qemux86-64 and qemuarm64

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2025-06-04 at 11:05 +0200, Alexander Kanavin wrote:
> On Wed, 4 Jun 2025 at 10:48, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > > I think bitbake-config-build should be extended to have
> > > 'list-machines/set-machine/list-distros/set-distro', and then
> > > bitbake-setup would call out to that, like it already does for
> > > fragments. There's already 'show-machines' in bitbake-layers, which
> > > should be renamed and moved, so that bitbake-layers is less
> > > over-stuffed with sub-commands.
> > 
> > Maybe. I do like the idea of being able to express a configuration with
> > just a list of fragments so a magic mapping of machine/XXX and
> > distro/XXX does still have some appeal. We could code something:
> > 
> > BBCONFIG_FRAGMENT_VARIABLE_MAPS = "machine/:MACHINE and distro/:DISTRO"
> > 
> > to make the code generic?
> 
> My idea was to do away with fragments for machine/distro, and have
> 'bitbake-config-build set-machine XXX' write 'MACHINE = 'XXX' into
> conf/auto.conf.

Let me just throw some ideas around here. I'm not saying any are
right/wrong, this is in the spirit of sharing ideas.

Moving the "machine" commands into one standard place would make sense
so I do like that aspect of what you're suggesting.

I have some caution about teaching "bitbake" commands machine/distro
specific as it breaks layers of separation. Note that bitbake-layers
list-machines is part of OE-Core, not bitbake.

I also have an idea in the back of my mind that being able to reproduce
common setups with a list of fragments would be a nice idea. If you
have to say:

set-machine XXX
set-distro YYY
set-features A B C

it isn't a very succinct explanation to people. If you can say:

set-features A B C machine/XXX distro/YYY

then it becomes a bit of a nicer thing for someone else to copy. This
is all generic in that someone else can add their own fragments. The
autobuilder can also then simplify configs too. Someone could add an
extra variable mapping for an extra level of config, say
toolchain/clang to set TOOLCHAIN = "clang", not that I'm suggesting
that specifically but you get the idea.

> And then bitbake-setup config files would have a particular syntax for
> that, e.g. replace the current:
> 
>             "qemux86-64-poky": {
>                 "description": "Poky reference distro build for qemux86-64",
>                 "oe-template": "poky-blank",
>                 "oe-fragments":
> ["core/machines/qemux86-64","yocto/distros/poky","core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl"],
>                 "targets": ["bitbake core-image-minimal
> core-image-full-cmdline core-image-sato-sdk core-image-weston"]
>             },
> 
> with
> 
>           "qemux86-64-poky": {
>                 "description": "Poky reference distro build for qemux86-64",
>                 "oe-template": "poky-blank",
>                 "oe-distro": "poky",
>                 "oe-machine": "qemux86-64",
>                 "oe-fragments":
> ["core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl"],
>                 "targets": ["bitbake core-image-minimal
> core-image-full-cmdline core-image-sato-sdk core-image-weston"]
>             },
> 
> I don't have a strong opinion either way, perhaps it's best to 'upload
> discussion data in brain and process', while fixing further do_unpack
> rework fails :) If you can respond with further points I'd appreciate
> that! (so I better see the forest)

playing devils advocate:

          "qemux86-64-poky": {
                "description": "Poky reference distro build for qemux86-64",
                "oe-template": "poky-blank",
                "oe-fragments": ["core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl", "machine/qemux86-64 distro/poky],
                "targets": ["bitbake core-image-minimal core-image-full-cmdline core-image-sato-sdk core-image-weston"]
            },

Cheers,

Richard