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 18:17
> 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 18:06, Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote:
> > > Otherwise, yes, I will say this:
> > > fix your scripts, and stop complaining.
> >
> > I can (and will) of course do that, but since I believe my fix is of
> > interest not only to us, but others who setup their environment
> > using the .templateconf file, my primary goal is to try to improve
> > upstream first.
> 
> Yes, but:
> 
> 1. There is no evidence anyone else except Axis is actually using
> .templateconf.

Since we obviously use our own distribution, I am limited in 
experience with other distributions. The one example I do know about, 
which I have mentioned before, is WindRiver. See line 831-835 in 
https://github.com/WindRiver-Labs/wrlinux-x/blob/WRLINUX_10_21_BASE/bin/setup.py
for an example of where they do basically the same as what we do.

> 
> 2. .templateconf is now officially retired as a way to set the
> template location. The patch you've sent is completely contrary to
> that: rather it makes the incorrect impression that it is still
> supported, and the implication is that the core upstream would still
> have to accommodate and think of those who are using it going forward.

Which is not entirely true, is it? Support for .templateconf I still 
there. I am only extending what is already there to work without errors 
for everyone, not just OE and Poky.

> Yes it's mildly annoying to delete the build directory, but can you
> just do it and move on? And yes, make a plan for replacing it with
> TEMPLATECONF, which is what I've been trying to squeeze out of you for
> I don't know how many times.
> 
> Alex

I do not understand what the problem with .templateconf is? There is 
a use case for being able to specify a default TEMPLATECONF, and that 
is what .templateconf satisfies.

There are currently three ways to specify where the templates files 
are (in order of preference):

1) TEMPLATECONF=
2) templateconf.cfg
3) .templateconf

In our case, the templates are always in the same location, thus we 
want to specify this as a default to give the developers a better 
user experience.

With the above three methods available, this is easy as we just set 
the default in the .templateconf file.

Now, if we remove support for .templateconf, how are we going to do it
instead? I can of course change our wrapper around oe-build-init-env 
to do TEMPLATECONF=${TEMPLATECONF:-path/to/our/templates} and this 
might seem fine at first. However, this means that the wrapper will 
always set TEMPLATECONF and thus templateconf.cfg looses its meaning, 
which to the user means that he must now always specify TEMPLATECONF= 
if he wants to set it to something other than the default where before 
he only had to specify it the first time he initializes a new build 
environment.

Or I can duplicate the calculations done in the OE scripts to figure 
out where BUILDDIR will end up to see if there is a templateconf.cfg 
file available, and then use that to set TEMPLATECONF if the user 
hasn't specified it. All of this duplicating upstream code, which 
may change with any future release. (Did I mention that I hate 
duplicating code?)

Now I understand that you have some idea that the user should always 
specify TEMPLATECONF=, in which case a default TEMPLATECONF has no 
value. But since we have a method for fetching exactly the layers 
that are to be used in a given build, to me it does not make sense 
to also have to specify a TEMPLATECONF to match what has already 
been fetched. It is just duplicating information, which IMHO is bad. 

What _I_ would prefer to see, is a way to specify that the build 
shall use the available layers. I.e., rather than a huge number of 
static templates configurations, I would like to see the 
initialization script take the layers as arguments, with the default 
being anything that matches meta* (or maybe more correctly, anything 
that has a conf/layers.conf file). As for the local.conf file, in 
my world, this would be made up from fragment files in the layers. 
So for any layer that ends up in the bblayers.conf file, the layer 
would be searched for any local.conf.XX files that would be 
concatenated together in the order of XX. This is (obviously) very 
similar to what we do today, so I am of course biased, but I think 
this model is a lot more appealing than static templates files. 
YMMV.

//Peter