RE: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates

[Peter Kjellerstedt <peter.kjellerstedt@axis.com>]

> -----Original Message-----
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> Sent: den 27 september 2022 23:50
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>; OE-core
> <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode
> invalid paths for templates
> 
> On Tue, 27 Sept 2022 at 23:31, Peter Kjellerstedt
> <peter.kjellerstedt@axis.com> wrote:
> > I am not too fond of the "writing the config directly" idea. The reason
> > for that is that things change upstream (as you are well aware of, that's
> > after all the whole reason for the discussion). This is why I prefer to
> > go through the templates and basically only provide the list of layers
> > to add. That way when things change upstream in the template files, we
> > automatically follow. (And if it has not been obvious before, our wrapper
> > uses the bblayers.conf.sample file from meta-poky and just replaces the
> > list of layers with our list of layers. Which of course sounds like then
> > we could just write the final config file directly, but we also want to
> > continue to rely on oe-init-build-env for determining _where_ to write
> > the final files.)
> 
> Wait, wait, wait. If so, you can initialize using the template from
> poky, then you get BBPATH or BUILDDIR placed in the environment (by
> oe-init-build-env) telling where the config files are. So you can
> write to them directly (e.g. local.conf), or use 'bitbake-layers
> add-layer' (or 'remove-layer') to tweak the list of layers using
> supported tooling -  after the initialization, but before any builds.
> No?
> 
> Alex

I am not sure if you are suggesting that the user shall run `bitbake-layers
add-layer` after sourcing oe-init-build-env, or if you mean that our wrapper 
should do it. 

If it is the former, then that is obviously not how we want things to work. 
The layers that are fetched shall by default be part of the build. That is 
an absolute requirement. There is no expectancy (or want) that the user 
shall have to add/remove the layers manually. 

If it is the latter, it wouldn't work (unless I yet again duplicate the 
code to figure out the build directory before sourcing the real 
oe-init-build-env) since before sourcing the real oe-init-build-env I 
cannot tell if there already is a bblayers.conf file in which case the 
wrapper should not add/remove any layers, and after sourcing the real 
oe-init-build-env it is too late as I then cannot distinguish between 
this being the first time oe-init-build-env is sourced or just a 
reinitialization of an already existing environment.

Our philosophy when we originally set this up was to keep it simple and 
as close to how OE/Poky works as possible. That way, if the developers 
have any questions and look at the Yocto documentation, the commands 
suggested there should work the same for us. And that is what we get 
from using the templates and letting the init scripts provided by OE do 
the work. The fact that we use the bblayers.conf.sample file from 
meta-poky rather than providing our own shouldn't change that. It is 
just a way to avoid having to manually keep our sample file in sync 
with what happens in OE Core.

//Peter