[bitbake-devel] Override a "_remove" operator in bbappend file

[Paul Eggleton]

On Tuesday 22 September 2015 14:35:39 Tim Jaacks wrote:
>Paul Eggleton wrote:
>>On Tuesday 22 September 2015 13:40:49 Tim Jaacks wrote:
>>> I have a problem with bitbake's "_remove" operator. Perhaps someone can
>>> help me out.
>>> 
>>> Suppose I have three layers:
>>>  - meta-1
>>>  - meta-2
>>>  - meta-3
>>> 
>>> In meta-1, there is a recipe "foo.bb", containing a variable:
>>> FOO = "bar baz"
>>> 
>>> In meta-2, there is an append file "foo.bbappend", which changes the
>>> variable using the "_remove" operator: FOO_remove = "bar"
>>> 
>>> The resulting value of the FOO variable is " baz".
>>> 
>>> Now I want to re-add "bar" to the FOO variable in meta-3, without changing
>>> the other layers. How is that possible?
>>> 
>>> I tried everything I could think of, including several combinations of
>>> "_append", "_prepend", machine-specific overrides, "_forcevariable" or
>>> setting the variable to a hard-coded value. Nothing could bring back
>>> "bar". It seems as if the "_remove" operator is always executed at the
>>> very end of the variable calculation, come what may. The layer priority
>>> seems to not have any impact on this.
>>> 
>>> Is this a design fault? Or am I missing something?
>>> Any hints on this would be helpful, thanks in advance.
>>
>> I'm afraid you cannot. _remove is intended to be final i.e. "remove this
>> after any and all other operations that might have added it". If you're
>> finding a _remove in another layer that's doing something you don't want,
>> then the layer is imposing policy on you that it probably shouldn't be.
>>
>> Is this _remove in a public layer? If so which layer and what is it?
>>
> thanks for your feedback. Yes, the according file is in meta-fsl-arm:
> 
> https://github.com/Freescale/meta-fsl-arm/blob/3336ef362109eef14f9e73cdededb
> 43caefedb2f/recipes-graphics/mesa/mesa_%25.bbappend
> 
> I would like to undo the first two lines.

Adding Otavio (the committer & maintainer of meta-fsl-arm) to CC - Tim perhaps 
you can explain what you're attempting to do here in concrete terms?
 
> So, this is the intended behavior, you say? Shouldn't the order of all
> _appends, _prepends and _removes be tied to the layer priority? That's what
> I would expect, though.

We went back and forth on the way it was implemented, but the conclusion we 
reached was that what most people want is a remove operator that removes the 
value no matter how it comes in. If we start getting into ordering of 
operators then it's harder for the user to understand what's going on, 
particularly as _append, _prepend and _remove are deferred operations (unlike 
+= or =+ which are immediate).

What this does mean is that _remove should be used sparingly and really ought 
to be used only where it's very unlikely that anyone would want to override 
it.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre