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. 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.
> 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.
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.
> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171130):
https://lists.openembedded.org/g/openembedded-core/message/171130
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]]
-=-=-=-=-=-=-=-=-=-=-=-
