Re: Should we change variable override formatting?
Richard Purdie
On Fri, 2021-07-16 at 14:35 +0000, Peter Kjellerstedt wrote:
I'm not sure it is going to be feasible to take two years to make this kind of transition. I've been looking for alternatives and one possibility may be semi-automated translation. By that, I mean that if you have a script with some knowledge of the layer it is translating, it appears from some quick tests locally that you can automate translation of a layer. My test was with poky (so bitbake, oe-core, meta-yocto and even the docs). The kind of knowledge a script needs is the names of the overrides in use and also function names or named parameter which contain keywords like "prepend", "append" and "remove". Once you prime it with that infomation, which a layer maintainer should have a good idea of, the script seems to be able to handle the bulk of translation. Code speaks volumes so: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/overrides-convert which has a script to translate poky, a commit of the translated content and a patch to bitbake to make it use ":" instead of "_" for overrides. I appreciate that translation like this isn't ideal, but it might just work well enough for people to work with to allow us to move forward. As to the actual syntax changes, one thing I would like to se is theI very much want to improve things. The trouble is if we try and do too much at once, we'll lose the support of our users. There are several things we're effectively trying to do: a) Add more information to the metadata (which text *is* an override?) b) Change the syntax to be more readable c) Remove certain syntax/operations d) Potentially change the behaviour of some of the syntax In the original thread, I was mixing up several of these things. I've tried to step back and try and just solve a) in a way we can agree on as a first step. If we can't even do that... Here is one suggestion:How do you explain PACKAGECONFIG{} += "foo" vs PACKAGECONFIG += "foo" to a user? I suspect that is the kind of thing which will cause us problems. [Just to be clear to everyone reading this, the problem is that .= and _append are not equivalent since the former applies to the default value, the latter to all possible values including overrides.] Right, I think elsewhere I said this form was usually error prone and not correct. I was considering dropping it, *if* we can get to a point where the parser can reliably detect it. This would also allow for clearing out the pending appends for aI like this idea. or:However: PACKAGECONFIG = "X" PACKAGECONFIG_bar = "" is a common usage. And a totally different solution (and probably more controversial) wouldI think these are getting too clever and steps too far beyond what we can cope with both in bitbake and with the developers we have. I can't begin to think how these would work in the code :(. As to RDEPENDS_${PN} & co, wouldn't it make sense to use RDEPENDS_pn-${PN},PN is really badly named since it is effectively the recipe name in many contexts. We're specifying one single thing in overrides with it rather than a suite of packages a recipe generates. I can't see how using pn- like that would work for the use cases we have for the package name override. On that note,We have tried to do this with newer overrides where it makes sense. It is a tradeoff between longer names and usability. I don't think adding something for the package name would help. Having "distro-" and "machine-" could help in some cases but it comes at the price of more complicated conversions and it becomes a question of whether things become more readable. Worth thinking about but the above list doesn't really make sense since features are in overrides. (PACKAGECONFIG should really be RECIPE_FEATURES if we're going to talk names!) Cheers, Richard |
|