[oe] getVar. setVar, "d", etc.

[Richard Purdie]

On Wed, 2008-02-06 at 10:54 -0800, K. Richard Pixley wrote:
> Richard Purdie wrote:
> > Once again I should remind people that := is usually a bad idea (see
> > recent discussions).
> That's counterintuitive and backwards from other build systems.  

Counterintuitive, yes, backwards, no. It does this differently since
bitbake works differently in general to other build systems. The
overrides syntax OE/bitbake uses is extremely powerful but has some
costs and this is one of them.

> I've often pulled significant savings out of makefile based systems by 
> switching from = to :=.  

This isn't a makefile based system.

> The problem being that "x = ${@ 
> a_long_running_function() }" is a killer, especially when 
> a_long_running_function is deterministic.  In that case, := requires 
> exactly one call during assignment while = requires a fresh call for 
> each and every reference. 

You need to think carefully about when bitbake will execute these
expressions. If a variable is never used, the code in it will never be
run. Most variables are not expanded and hence any functions are not run
during initial parsing. They may run when the recipe is executed but any
time taken at this point isn't usually a problem.

> I used := in this situation specifically because of the sequence 
> ordering.   The assignments in my example are dummies whose sole purpose 
> is to force the side effects to happen at a predictable and early point 
> in the run - specifically, before the assignment to SRC_URI.  If I don't 
> force the side effects to happen at := time, then there's no reason to 
> believe that they will have occurred prior to the expansion of ${PR} in 
> ${SRC_URI}.  (And, in fact, changing this doesn't affect my results).
> 
> I have discovered that converting the constructions into "python 
> setting() {" seem to give them consistent contexts.  I don't understand 
> why ${@ ... } lacks that context, but at least I have a way to proceed. 

The "anonymous" functions are run after the file is parsed but before
the data is used.

${@...} runs when the variable is expanded.

> Event handlers also seem to have consistent context so if I can reverse 
> engineer what events actually exist, or force one to occur at the right 
> time, then I should be able to get my assignments done early enough.
> 
> Neither these differences nor event handlers are very well described in 
> the manual, btw.

Patches welcome!

Regards,

Richard