Re: [poky] [PATCH 1/2] meta-poky/conf/templates/default/bblayers.conf.sample: do not assume integrated poky repo

On Tue, 24 Jun 2025 at 15:58, Richard Purdie
<[email protected]> wrote:

> > Right, this refers to the poky integration process that cherry-picks
> > files and directories from original repos, e.g. the default template
> > from oe-core (meta/conf/templates/default) does not make it into poky
> > at all.
> >
> > The patch follows the suggestion that such a tweak is possible:
> > https://lists.openembedded.org/g/openembedded-architecture/message/2129
>
> Ah, that is a bit different. There aren't tweaks of a similar nature.
> I'll need to give this more thought...

I want to put my thoughts (and a proposal) forward: the real issue
here is that BBLAYERS is a list of full paths, and thus is not
relocatable. And there's lots of awkwardness around changing that list
relative to ##OEROOT## and back in templates (and ##OEROOT##-prefixed
paths are still not relocatable).

I tried to think of a way to specify layer identifiers instead, and
have some kind of 'magic' figuring out where the layers are in the
filesystem. One option is something like this:

BBLAYERS_SEARCH_PATHS = "/path/to/where/layers/are /some/other/path/with/layers"
BBLAYERS_IDS = "core yocto intel"

e.g. bitbake would walk the filesystem starting from those paths (they
would be set by bitbake-setup or other tools performing layer
checkouts), and add any matching layers to the build.

I think that's actually not too horrible. Should I try to prototype
this? One nice consequence is that it makes templates optional for
those who do not like them: one could instead set the build entirely
from just a list of fragments (machine/distro built-ins at a minimum
:) and layer ids. Having to maintain templates for any possible layer
combination doesn't scale, same way as on-disk fragments for
machines/distros wouldn't scale.

Alex