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. The questions we need ask when considering new additions to the syntax like that are: a) How often is the syntax needed? b) Is it consistent with the other syntax we already have? c) Is use of the new syntax likely to cause any systematic worsening of the usability of the overall metadata? d) What are the performance implications? The immediate expansion operator (:=) is both a blessing and a curse in this regard as it is needed to do some things which would otherwise be "impossible" but equally, it puts some nasty constraints on the parser. Since we already have :=, we already have the parser problem. Performance wise, I guess this would mainly add the complexity of scanning all variable names for another string match. I'm not against it, I'm not enthusiastic either :). I'd be interested in Chris' thoughts on this. Cheers, Richard _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
