On 7/28/21 10:43 AM, Richard Purdie wrote: > Hi All, > > I've spent quite a bit of time seeing how to progress things. I now > have a script which can convert layers and seems to have reasonable success > on OE-Core, bitbake, yocto-docs, meta-yocto, meta-gplv2 and meta-mingw. I've > proposed this for OE-Core along with an example conversion patch for OE-Core. > > The current patch status is I have conversions (including to bitbake's core) > in master-next branches. This nearly has q-quick builds passing on the > autobuilder, there are a handful of oe-selftest cases which don't pass yet. > > Things do get a little more complex than I'd hoped. We use OVERRIDES > in a number of interesting places, including within multilib configurations > for the tune-XXX variable suffixes. I did try making the code do "fallback" > variable lookups instead of expansion for tune- but I quickly gave up due > to the nesting. My view is that they are being used as overrides and we > should > therefore recognise them as such. Over time I think the tune code can be > improved to take explicit advantage of that. > > As such, I'm proposing we make the package variables and tune variables > explicit overrides and the conversion scripts and patches above assume this. > > I think the challenge is going to be the flag day issue for master branches. > For example, there is code in devtool and other places which knows about the > override character. If we allow mixing the different syntax for master then > those tools need to complicate things by referencing both characters. To try > and preserve what is left of my sanity, I'm starting to think we just require > layers to migrate to the new syntax to continue to work with master. The good > news is that those converted layers should work with dunfell and older > releases > where the layer already does that with the backported bitbake syntax update. > > If we accept that we need to have a flag day for master use, the question is > when. We could pick some data well in the future or even post 3.4 however I'm > not sure this buys much and we probably may as well get on and do it. > > Given these things, I therefore propose that we should start these changes > and require it for master, probably relatively quickly within a couple of > weeks?
Sooner the better is my view... Thanks for all of this, I know it's going to make things better longer term no matter when it switches over to the new format. (Also making the tune-XXX a first class override makes sense!) --Mark > Cheers, > > Richard > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1294): https://lists.openembedded.org/g/openembedded-architecture/message/1294 Mute This Topic: https://lists.openembedded.org/mt/84508148/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
