On Fri, 2020-07-03 at 14:08 -0700, Christopher Larson wrote: > I definitely think there’s a usability issue here. It’d be nice if > +=/=+/.=/=. were recorded operations against the current or default > value. Now that _append/_prepend/_remove are applied at getVar time, > not at the end of the parse, I could see the other operations working > the same way, just the non _ operators would be reset in certain > contexts, ex unset or assignment to a non-default value. I think this > would be the ideal way forward. If done the right way, I don’t think > this would necessarily have to break current semantics regarding > assignments to the current value undoing the previous +=/=+/.=/=.
I agree, having +=/=+ and friends operating against the default value would in general be the behaviour most people want/expect. The change in behaviour would be that "=" would no longer wipe out previous +=/=+ ops. Its probably worth an experiment to see how much that would break. I think if we could make that work, most ?= could become ??= and ?= could be phased out as its += not working on ??= that is the current pain point as I understand it. > It’s not enough to keep ??= and deprecate ?= due to their differing > behavior. The *last* ??= wins, so if a bbclass uses ??= to define a > default value, it’ll use that in preference to a defined ??= default > from the configuration metadata, which wouldn’t be what you’d want. > So either the configuration metadata has to never use ??=, a matter > of policy, or a bbclass has to use ?=, or define its fallback default > in its code rather than in a variable assignment. This is why I > always use ?= for bbclass defaults, they shouldn’t override default > configuration, even if it wasn’t user configuration. I did try and standarise something for PACKAGECONFIG in recipes but sadly with the current status quo, you can't keep everyone happy (those that want to set their own value and those that want to define a set of changes). > That is, a distro may want to define a default that’s used in > preference to the bbclass default, but not used in preference to the > value defined in local.conf. In that situation I could see the distro > using ??= and the bbclass using ?=. Of course, there are > alternatives. If we expect the user to either always use overrides in > local.conf, or always use explicitly provided hook variables, not the > ones actually used by the implementation, then it’d be a non-issue. I'd say the "base" definition uses ??= and then all other reassignments use "=", then ordering wins. The reason people don't do that today is that +=/=+ and friends are lost. > There are obviously *many* use cases to consider here given how > widely the project is used and the differing operation orders amongst > the numerous variables we have. Any replacement would have to be > validated to not change any variable in any recipe from the current > behavior. That can at least be validated more easily now! :) Yes, I do agree, it needs a lot of careful thought and then testing. I do think its something we should think about though. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1097): https://lists.openembedded.org/g/openembedded-architecture/message/1097 Mute This Topic: https://lists.openembedded.org/mt/75280300/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
