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. /Esben _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
