Maybe we could ask, what are the typical intentions behind those additions and removals and assignments? E.g. for DISTRO_FEATURES I can think of these:
1. Features A B C can be present in DISTRO_FEATURES if no other wish is expressed 2. Features D E F must be present in DISTRO_FEATURES 3. Features G H I must not be present in DISTRO_FEATURES. It would help if the following is guaranteed to happen (and currently it does not): - type 2 list never affects type 1 list (or vice versa), Several lists of type 1 or type 2 produce a union of all items. - if a type 3 list conflicts with a type 2 list, then bitbake stops and prints an error. Specific syntax is secondary to intentions that we want to make easy to express. Alex On Fri, 3 Jul 2020 at 20:44, 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 (#1096): https://lists.openembedded.org/g/openembedded-architecture/message/1096 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]] -=-=-=-=-=-=-=-=-=-=-=-
