> -----Original Message----- > From: Richard Purdie <[email protected]> > Sent: den 22 september 2022 22:33 > To: Alexander Kanavin <[email protected]>; Peter Kjellerstedt > <[email protected]> > Cc: [email protected] > Subject: Re: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode > invalid paths for templates > > On Thu, 2022-09-22 at 17:52 +0200, Alexander Kanavin wrote: > > .templateconf is not the way to specify the location of custom > > templates, and never was. > > That much isn't true. It was a way this has been done, it was suggested > as a way people do it and it was even documented as such. The original > commit does make the intent clear: > > https://git.yoctoproject.org/poky/commit/.templateconf?id=614faa66a442069b8cd81ee74a01ecc5d73870d9 > > I think the key point is that it has been of limited use as it requires > a custom repo due to the use of OEROOT. Where you had a custom repo, it > was fine to use. Poky was one example. > > I haven't read back through the discussions but I suspect Peter must > have some kind of custom repo setup like that to be able to alter files > in OEROOT.
Yes, and it is very simple to do when using `repo` like we do. Just add a <copyfile> line in the manifest that tells `repo` to copy a .templateconf file from a suitable repository and place it in the root. > > It got added to documentation by misunderstanding, > > Again, I'm not sure about that. I think at the time, when layers were > much newer things and technology was more in flux, we did think this > was a valid customisation. At the time we were suggesting people might > want to use tools like combo-layer to mess with repos. > > What the documentation doesn't make clear is that this trick only works > for repo alterations as far as I can see. See above. At least in the case of using `repo` to fetch the layers, this way of specifying the default template makes perfect sense. > Since we don't recommend such repo alterations now and combo-layer is > pretty dead, the code is of limited use and I do think it probably > should be removed. I therefore don't like adding complexity to > something which really shouldn't be there at all. I appreciate this > does looks like it creates a challenge for Peter's situation though. The expectation I have on Yocto is that whatever is fine and works for Poky should also be fine and work for anyone else setting up the environment in the same way. I.e., for Poky I expect the following: * Fetch the distribution (poky). In this case a simple git clone with the URL to the poky repository and the wanted version. * Change to the newly fetched directory. * Run `. ./ oe-init-build-env`. Which in our case corresponds to: * Create and change to a new directory. * Run `repo init` with the URL to the manifest repository, its version and the manifest to use, followed by `repo sync`. * Run `. ./ oe-init-build-env`. So, as long as the layers with their correct versions have been fetched, all I should have to do is run `. ./ oe-init-build-env`. That is what we have always done, and I am not going to change that. Changing that would be a huge undertaking for no gain to us. Now, the above works since I have modified our wrapper to create the template files in "templateconf/templates/axis" rather than the old "templateconf" and to create a dummy layer.conf file so the new requirements are satisfied. The problem is that because how the templateconf.cfg file is read, its value overrides the default in the .templateconf file and thus anyone updating an existing build tree to Langdale faces an error because the old templates path is unlikely to satisfy the new requirements. This is why the code in scripts/oe-setup-builddir was changed to remove the old templateconf.cfg file if it contains a known bad path. Since I of course do not want for my developers to face this error when they update, I have two options: 1) I can remove the old templateconf.cfg file in our wrapper. This means I have to duplicate the code in scripts/oe-buildenv-internal that calculates the BUILDDIR variable. It also means I will have to keep and maintain this code for the foreseeable future. 2) Change the code in scripts/oe-setup-builddir so that it is not hardcoded to only support OE and Poky, but instead is generic and works the same for anyone. From my point of view, option 2 should be the natural choice. > I have put off touching this particular area of code since I know there > will be a ton of problems exactly like this. The success or failure of > such changes does depend on how the migration is handled. A large part > of this is communication and to some extend negotiation too. The fact > I'm having to start trying to understand all the details is the > situation I didn't really want to be in. > > I suspect to get anywhere I now need to go and read all the previous > threads to then try and unravel this :/. > > Peter: is there a pointer you can give to the setup you're using? I gave an example in https://lists.openembedded.org/g/openembedded-core/message/170677. Is that what you were looking for? > > Cheers, > > Richard //Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171106): https://lists.openembedded.org/g/openembedded-core/message/171106 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]] -=-=-=-=-=-=-=-=-=-=-=-
