On Fri, 2020-07-03 at 23:23 +0200, 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.

Yes, I think we're talking about the same thing, its just a different
way of thinking about it. I'm adding the challenge of trying to figure
out what changes to existing behaviour we could consider to get us
where we need to be (or as close as is realistic) or if we have to
change some operator(s).

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Reply via email to