Re: Variable key replaces original warnings

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2015-07-31 at 13:48 +0200, Olof Johansson wrote:
> Excerpts from Richard Purdie's message of 2015-07-31 12:00:06 +0200:
> > The OE-Core change I made for a similar case was:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/update-rc.d.bbclass?id=3b627bb28c4ea2ea33050ad4884c6351e2d6ebad
> > 
> > i.e. moved to anonymous python. Not ideal, but more explicit.
> 
> Ah, thanks. Didn't see this before replying to your other mail. But I
> agree, not ideal at all. It's very surprising. What I would expect is
> that the _append is postponed and only done on the expanded vars, but
> that's not the case? Why not?

Its all about the timing of the override expansion (_append is
effectively an override) and the key expansion. Taking:

PN = A
RRECOMMENDS_${PN} = "X" 
UPDATERCPN = "${PN}" 
RRECOMMENDS_${UPDATERCPN}_append = "Y"

if you expand overrides first it changes to:

RRECOMMENDS_${PN} = "X" 
UPDATERCPN = "${PN}" 
RRECOMMENDS_${UPDATERCPN} = "Y"

and it then becomes:

RRECOMMENDS_A = "Y"

however if you do key expansion first it becomes:

RRECOMMENDS_A = "X" 
RRECOMMENDS_A_append = "Y"

so RRECOMMENDS_A = "XY" 

We're now using the former rather than the latter in bitbake however it
will generate warnings where it sees variables conflict since users tend
not to realise and mean something different.

Worst case we could make the warnings configurable or whitelist them but
simply changing the code not to be ambiguous is likely the best all
around solution.

Cheers,

Richard