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 +=/=+/.=/=.
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. 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. 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. -Chris On Jul 3, 2020, 11:44 AM -0700, Konrad Weihmann <[email protected]>, wrote: > I totally agree that there is an usability issue. I myself have been > confused for a long time about all these options and how they work > together (or don't) and having now a hard time telling other ppl to > avoid some corner cases. > > For me the difficulty arises from this multi-stage processing. > On the one hand we have "=", "+=", "=+", ".=", "=." which are solely > working according to the flow of instructions - so it is directly > depending on the order of files processed. > > And then we have the 2nd and 3rd stage operator "_append", "_prepend" > and "_remove", which only act on the outcome of the first stage (which > is even now hard to predict in some cases). > > And finally we have "unset" which is far more hard to understand as it's > resets everything based on the instruction flow but also partly the > 2nd/3rd stage modifier (IIRC) > > If I could start from scratch I would only go with > - weak default " ?= " > - hard set " = " > - append and prepend operations " += ", " =+ " > and base them all on solely on the instruction flow, which would also > would remove the part of another (hard to grasp) dimension: layer > priority, as then only the order of the layer in BBLAYER would determine > the final flow. > > But as we can't, I would say > > - " ??= " for defaults > - minimize the usage of 1st stage operator "+=", "=+", ".=", "=." and > replace them by "_append" and "_prepend" (which would eliminate the need > for .= and =. btw) > > I know this might be controversial, but I've seen multiple examples of > the scenario described below, where a weak default was silently > overridden, which is hard to debug (and as Martin Jansa already wrote > the only way to really check this is using bitbake -e). > Having a 5 or 10 level layer cake makes it even harder to check all the > cases. > > And finally if the core layer have adapted to this pattern > - retire the operators "+=", "=+", ".=", "=." > - maybe also " ?= " should be retired, as it should be covered by " ??= > " if the above is really given > > If there shouldn't be any changes one could also add some sanity check > into the parser to at least warn ppl that there is something happening > that they might not be aware of. > > But certainly I don't see the need to introduce another operator > > On 03.07.20 16:31, Richard Purdie wrote: > > I'm growing increasingly concerned about default value assignments in > > OE. The basic problem is people don't understand the way default values > > work and the mechanisms we do have don't let people do all the things > > they want to do. > > > > I'll pick on the example found by Ross/Jon in meta-arm. If you set: > > > > BB_HASHBASE_WHITELIST += "X" > > > > in layer.conf, the BB_HASHBASE_WHITELIST ?= "Y" from bitbake.conf is > > lost as by then the variable already has a value. Another user reported > > the same issue today in irc. > > > > Another example would be whether recipes should set PACKAGECONFIG with > > "=", "?=" or "??=". All work well for some scenarios and not for > > others, often depending on whether the user wants to add to or remove > > from the original value, or change it to something else entirely. > > > > We then have a complete lack of standarisation of how bbclass files set > > default values. > > > > I don't have a fully thought out solution to all of this at this point. > > I think it is clear out existing syntax isn't really capable of > > expressing everything we need though and confusion current reigns. > > > > I was partly responsible for introducing "??=" as a syntax for > > "default" value. The problem with it is that "+=" doesn't modify it, a > > deliberate (and necessary) choice at the time which makes it pretty > > ineffective. > > > > If bitbake started tracking whether an assignment has been used on a > > given value vs. just += and =+ it would be possible to have an operator > > which could have a behaviour more in line with what users expect? > > > > Whether that could/should be some new assignment operator, or whether > > we could "rescue" ??= I'm also not sure. A new operator would certainly > > be safer. > > > > Does anyone else: > > > > a) Agree there is a usability issue here? > > b) Think we should try and do something? > > > > If so, what should we do, what is the behaviour we really need/want? > > > > Cheers, > > > > Richard > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1095): https://lists.openembedded.org/g/openembedded-architecture/message/1095 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]] -=-=-=-=-=-=-=-=-=-=-=-
