First of all, I would like to understand why writing to .templateconf cannot be replaced with specifying TEMPLATECONF= in your setup.
Then we can maybe proceed to the similar question asked earlier about replacing writing to bblayer.conf with using bitbake-layers to adjust the layer list. There was also a question about removing the step of creating a custom template altogether, and just writing a build configuration directly. Where are the answers to those, Peter? Alex On Thu, 22 Sept 2022 at 22:32, Richard Purdie <[email protected]> wrote: > > 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. > > > 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. > > 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. > > 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? > > Cheers, > > Richard > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170995): https://lists.openembedded.org/g/openembedded-core/message/170995 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]] -=-=-=-=-=-=-=-=-=-=-=-
