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 (#1094):
https://lists.openembedded.org/g/openembedded-architecture/message/1094
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]]
-=-=-=-=-=-=-=-=-=-=-=-
