> -----Original Message----- > From: Alexander Kanavin <[email protected]> > Sent: den 27 september 2022 18:17 > 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 18:06, Peter Kjellerstedt > <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171123): https://lists.openembedded.org/g/openembedded-core/message/171123 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]] -=-=-=-=-=-=-=-=-=-=-=-
