On Mon, 2011-04-04 at 12:59 +0200, Esben Haabendal wrote:
> Richard Purdie <[email protected]> writes:
> 
> > On Sat, 2011-04-02 at 11:29 +0200, Esben Haabendal wrote:
> >> Esben Haabendal <[email protected]> writes:
> >> 
> >> > Hi
> >> >
> >> > Trying to figure out the expected behavior of variable assignments.
> >> >
> >> > FOO = bar
> >> > BAR_bar = 1
> >> > BAR_${FOO} = 2
> >> > BAR_bar = 3
> >> > BAR_${FOO} = 4
> >> > BAR_bar = 5
> >> >
> >> > gives
> >> >
> >> > BAR_bar = "4"
> >> >
> >> > Where/when is the variable names being expanded?
> >> >
> >> > And wouldn't it make more sense if variable names were expanded
> >> > immediately, so that the above code would produce BAR_bar="5" ?
> >> > I at least would find it less surprising.
> >> >
> >> > Of-course, this would be a change in semantics, but the fallout might be
> >> > minimal, and it should be possible to check for it given specific
> >> > meta-data.
> >> 
> >> Hmm...  Of-course, all the FILES|SECTION|RDEPENDS|RRECOMMENDS_${PN}* in
> >> bitbake.conf actually on the current semantics.
> >> 
> >> Perhaps it would make sense to add a new syntax for using immediate
> >> expansion in the variable name, fx.
> >> 
> >> BAR_$${FOO} = "6", which would then assign "6" to the variable name
> >> expanded immediately.
> >
> > As you say, a lot depends on the current semantics so changing this kind
> > of behaviour isn't easy. The deferred expansion is at least consistent
> > with the behaviour of other expansions.
> 
> Instead of adding immediate variable name expansion, the current syntax
> could be changed to still do late/delayed variable name expansion, but
> let the last assignment win.  By giving each assignment an incremental
> assignment-number, contest between multiple variables names could be
> resolved by the latest assignmnet.  Not sure exactly what would be the
> natural way to handle appends and prepends in such a scenario though.

This would be totally unlike any behaviour we currently have. Wouldn't
that just add more confusion to the mix?

Cheers,

Richard

_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev

Reply via email to