On Fri, 2020-07-03 at 20:44 +0200, Konrad Weihmann 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 " ?= "
Presumable this would behave like ??= though (?= as implemented is fairly flawed but so is ??= today, sadly). > - 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. I have to admit if I was implementing layers again, I'd want to ditch a load of the older "collections" bits we brought in for compatibility. > 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'd much rather general _append fell out of use in favour of a += and =+ that did what the user expected and the append syntax only remained in general use for overrides. I guess in my discussion with Chris we're effectively talking about mapping += and =+ to append. > 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 It depends how we want to consider compatibility and migration but yes, more operators probably isn't going to make people happy. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1099): https://lists.openembedded.org/g/openembedded-architecture/message/1099 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]] -=-=-=-=-=-=-=-=-=-=-=-
