I've long felt the use of ??= was not ideal, as it's prone to breakage. A user unintentionally using += will blow away the default entirely, which is almost certainly not what they intended, and if they do it in local.conf, it'll do so for every recipe they build.
On Tue, Dec 19, 2023 at 1:46 PM Alex Kiernan <[email protected]> wrote: > On Tue, Dec 19, 2023 at 8:20 PM Joshua Watt <[email protected]> wrote: > > > > All, > > > > This message is to start a discussion about removal of undesired > > recipe PACKAGECONFIG options. > > > > Background: > > Since the dawn of using OpenEmbedded as part of my day job, we've used > > meta-gplv2 to avoid GPLv3 code in our products. However, I recently > > decided that it was past time to excise this particular wart from our > > code base, so I've been looking at how to do this. Ideally, I would > > like to make it some sort of shared .inc file that can be included and > > we can all collaborate on to make it easier for this fairly common use > > case. > > > > > > One of the major things that comes up frequently is that the > > PACKAGECONFIG for a recipe needs to be modified to remove some > > incompatible flag from the default options. This particular option is > > not very simple though, because most recipes set PACKAGECONFIG using > > the "deferred weak" assignment, as in `PACKAGECONFIG ??= "foo bar"`. > > Because of this, any operation that attempts to modify this variable > > will overwrite the default; commonly one might like to do something > > like `PACKAGECONFIG:remove = "foo"`, but since this happens before > > weak assignment, the result is an empty string instead of just the > > value "bar". > > > > I've come up with a number of solutions for this, but I'm unsure which > > ones make sense to explore as long term options for the project: > > > > 1) Do nothing and respecify the complete set of PACKAGECONFIG options > > when overriding. This basically means instead of PACKAGECONFIG:remove > > = "foo", you would explicitly set to the remaining items like > > PACKAGECONFIG = "bar". If no other solution is appealing, this is > > probably fine, and what I'll do. The main reason I don't like this is > > because package configs are frequently added to recipes and it's > > annoying to keep them in sync (mostly, because I'm lazy :) ). > > > > 2) Add a PACKAGECONFIG_REMOVE variable that is evaluated by the > > package config code and causes it to ignore any matching items. This > > one is pretty easy in the packageconfig code, and I think users would > > find it pretty easy to understand. The downside is that it's very > > specific to packageconfig; there are other variables that probably > > would want similar treatment, but it may not make as much intuitive > > sense to do for them also (e.g. IMAGE_FEATURES, DISTRO_FEATURES). > > Also, much like :remove, you wouldn't want this used in actual > > recipes; it should only be set by end users. > > > > 3) Change the order of weak assignment vs. remove. This one is a > > little trickier but the idea is that if ??= and :remove don't make > > sense in their current order, flip around the order of evaluation so > > that it does make sense (e.g. apply :remove after ??=). I'm not sure > > how easy this would be and if it could be done all the time, only when > > a variable was a "list", or some other criteria > > > > 4) Stop using ??= for default PACKAGECONFIG. I'm not sure the history > > as to why it's ??=, but switching it to ?= (or maybe even =) would > > solve the problem because then :append, :remove, +=, et. al. would > > work as expected. The only case I can think of where this wouldn't > > work is if a bbappend was doing a ?= to set a completely new set of > > default PACKAGECONFIG flags; I'm not sure why that would be necessary > > though. Are there any other cases I've not thought of? > > > > At some point I picked up the strong message that this was the > preferred approach and have used it since (and it makes sense to me). > For the set of layers I have in my default poky testing build there's > 490 which have ??= and 146 which have ?=, so clearly a majority, but > not a completely overwhelming one. > > > 5) Add "filters" to variables. The basic idea behind this one is that > > variables would get a new flag called "filter" where pipelines of > > limited expressions could be constructed. These filter expressions > > would be applied after the final value of the variable (and thus, > > after weak assignment). For this specific case, this might look > > something like: `PACKAGECONFIG[filter] = "remove(v, 'foo')"`. This is, > > admittedly, a _very_ general solution for this particular problem. > > However, this concept has been discussed in other contexts such as > > multilib and BBCLASSEXTEND, so if it is something that would help > > there, this problem could leverage that solution also. If you want a > > peek at what this might look like, there is a jpew/bb-filters branch > > in poky-contrib > > > > > > If you have any thoughts or other possible solutions, please let me know. > > > > Thanks, > > Joshua Watt > > > > > > > > > -- > Alex Kiernan > > > > -- Christopher Larson [email protected], [email protected], [email protected] Principal Software Engineer, Embedded Linux Solutions, Siemens Digital Industries Software
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1884): https://lists.openembedded.org/g/openembedded-architecture/message/1884 Mute This Topic: https://lists.openembedded.org/mt/103269425/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
