Yeah that pretty much sums up the use cases - the question (and I guess
tricky part) is about "no other wish is expressed" - and here, I think,
something should be done, as it's not very intuitive for the user.
On 03.07.20 23:23, Alexander Kanavin wrote:
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]
<mailto:[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 (#1105):
https://lists.openembedded.org/g/openembedded-architecture/message/1105
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]]
-=-=-=-=-=-=-=-=-=-=-=-
