<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 1:53 AM, Tim Jaacks <span dir="ltr"><<a href="mailto:tim.jaacks@garz-fricke.com" target="_blank">tim.jaacks@garz-fricke.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":22w" class="a3s" style="overflow:hidden">Hello Otavio & Paul,<br>
<br>
thanks for your replies.<br>
<span class=""><br>
> It seems you are intending to use mesa for i.MX5 SoC, the way I would do it<br>
> would be removing the mx5 from the overrides completely.<br>
<br>
</span>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.<br>
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.<br>
<span class=""><br>
> We went back and forth on the way it was implemented, but the conclusion we<br>
> reached was that what most people want is a remove operator that removes the<br>
> value no matter how it comes in. If we start getting into ordering of<br>
> operators then it's harder for the user to understand what's going on,<br>
> particularly as _append, _prepend and _remove are deferred operations (unlike<br>
> += or =+ which are immediate).<br>
><br>
> What this does mean is that _remove should be used sparingly and really ought<br>
> to be used only where it's very unlikely that anyone would want to override it.<br>
<br>
</span>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.<br></div></blockquote></div><br>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.<br>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>