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

[Christopher Larson]

On Mon, Sep 28, 2015 at 1:53 AM, Tim Jaacks <tim.jaacks at garz-fricke.com>
wrote:

> Hello Otavio & Paul,
>
> thanks for your replies.
>
> > It seems you are intending to use mesa for i.MX5 SoC, the way I would do
> it
> > would be removing the mx5 from the overrides completely.
>
> Yes, that is exactly what I want to do. We do not want to move to master,
> as we use the 3.0.35 kernel and have tested our systems on this version,
> and changing this would result in a lot of new work.
> You mean, I should remove "mx5" from SOC_FAMILY? Well, that would work of
> course, haven't thought of that. However, I would have to rewrite lots of
> other variable assignments with overrides for my specific hardware. And
> this wouldn't be very intuitive at all, because my hardware IS based on an
> mx5, and thus looking into the recipes I would assume that _mx5 overrides
> are applied on my hardware.
>
> > 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.
>
> Well, I would say that this is somewhat counter-intuitive. The layers are
> one of the main concepts of Bitbake. If I create a layer and assign the
> highest priority to it, it is hard to understand that changes I make to a
> variable in my layer are not applied because of a lower priority layer
> being processed after my layer. How can you ever tell that it is "unlikely"
> that someone wants to override a _remove operator? Shouldn't ALL variables
> be changeable in ALL ways? This seems a very strict (and undocumented)
> limitation to me.
>

Remember that _remove is usable in global configuration context as well. We
need the user to be able to remove something from local.conf which added in
a recipe, but if we blindly follow the order of append/prepend/remove
operations, it wouldn't work as expected, as the configuration metadata is
parsed long before the recipes.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20150928/7ea07a3b/attachment-0002.html>