> -----Original Message-----
> From: Alexander Kanavin <[email protected]>
> Sent: den 27 september 2022 21:58
> To: Peter Kjellerstedt <[email protected]>
> Cc: Richard Purdie <[email protected]>; OE-core
> <[email protected]>
> Subject: Re: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode
> invalid paths for templates
>
> On Tue, 27 Sept 2022 at 20:53, Peter Kjellerstedt
> <[email protected]> wrote:
> > 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.
>
> Yes, they have to fix this too. And not by replacing .templateconf
> with TEMPLATECONF, but by writing a config directly, particularly
> using available tooling to compose bblayers.conf.
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.)
> Templates are
> intended for layers and version control, not as an extra intermediate
> step when setting up builds - the goal is to standardize build
> configuration management, and static templates is a starting point.
>
> > 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.
>
> I'd say it does not satisfy the use case, as it relies on being next
> to oe-init-build-env, which in turn requires custom scripting. Show
> how to do this using standard tools in core/poky, write a patch for
> the official documentation, and then you have a point.
Well, up until now there have been no tools in OE/poky to do anything
related to setting up the layers, so I will go by the tools that I
know are actually being used.
With repo and git submodules it is simple to setup the .templateconf
file to match the distribution. I cannot speak for kas, as I have never
used it, but I believe it uses its own way of doing things. I have
tried whisk, though it was a while ago, but if I remember correctly,
it also wrote the files itself. And, as of yet, I have not tried your
new tools, but I plan on doing that as soon as I have the time, though
I am pretty sure they do not rely on .templateconf. ;)
>
> > 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.
>
> I get this, it is useful to make a pointer to a 'default' template
> when you have a set of layers, but the tooling for managing a modified
> .templateconf is absent. As things are, it is useful only as a
> fallback to the default core/poky template.
Or anyone who sets up their distribution to mimic OE/Poky...
> And if you propose such tooling, it somehow has to avoid modifying any
> of the layers after they have been fetched. 'repo' allows you to do
> this, this doesn't mean it would be an acceptable thing to do in
> general. I did think about it, and I don't have good or even workable
> ideas.
>
> > 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.
>
> I'm not sure I understand this. If the build environment has been
> initialized before from templates, values of TEMPLATECONF or
> templateconf.cfg become irrelevant, as the files in build/conf/ are
> already in place, and scripts will skip copying them over from
> templates. So you can continue to *not* have to specify TEMPLATECONF
> when you want to reuse an existing build directory without changing
> anything in it.
>
> First time:
> TEMPLATECONF=path/to/template . oe-init-build-env (will copy from
> template)
>
> Second+ time:
> . oe-init-build-env (will detect that no copying is needed, regardless
> of where the template is set to)
>
> Can you describe the sequence of commands where the problem arises? If
> there is a problem here I absolutely want to see it.
Well, the real problem is that since the path _is_ stored in
templateconf.cfg and this path takes precedence over the path in
.templateconf, it causes problems if it is not updated, due to the
new requirements on the stored path, whether it is actually used
or not. :( This is what my patch tries to address.
However, having the path stored in templateconf.cfg is only really
useful for anything if you delete one or more of the generated files
so that they need to be regenerated. I assume that is why it was
done, but I really do not know.
We use this feature in a help script we have, where you can have it
update the config files by giving it an --update option, in which case
it just deletes the old files in the config directory and then relies
on oe-init-build-env to regenerate them. We could of course have solved
this some other way, but since the feature is there, why not make use
of it?
That said, having a simple way like that to update the config files
is also something I would not mind seeing upstream. What we do in the
local.conf is that we add a marker line at the end. Then when the
user uses the --update option, we keep anything after that line but
regenerate anything before it. So typically you add, e.g., MACHINE=
at the end and then it is simple to update the file after an update
to a new version of OE. This may not be the way local.conf is
intended to be used, but I find it hard to use it if you actually
uncomment any of the existing lines and then want to update the file
to match a new version of OE. Thus I only use the existing lines as
examples and do any modifications at the end.
But as I said, this is a convenience script that some of our users
use and not part of the wrapper we have for oe-init-build-env.
> > 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.
>
> Yes, config fragments are the next step. Whether they be automatic
> like you prefer, or manual ('oe-setup-build add systemd') or both is
> to be determined.
>
> Alex
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171133):
https://lists.openembedded.org/g/openembedded-core/message/171133
Mute This Topic: https://lists.openembedded.org/mt/93847437/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
