[OE-core] proper "style" for VAR_append_override?

[Paul Eggleton]

On Saturday 07 March 2015 09:43:34 Robert P. J. Day wrote:
>   more nitpickery, but i've noticed a couple different ways in the OE
> code base and documentation for conditionally appending based on an
> override, and it might just be that i'm confused about the underlying
> mechanics of the append operators.
> 
>   first, there's this from qemu.inc:
> 
> KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
> 
> i've always read that as, "if override of linux-yocto package is in
> effect, then add this feature to KERNEL_FEATURES using the "append"
> operator, which will leave the appending to the end and, in addition,
> *requires* that we explicitly have that leading space given that we're
> using _append.
> 
>   it's also my understanding that i can have multiple assignments like
> that (possibly based on different overrides), and they will all be
> processed properly and finally appended to (in this case)
> KERNEL_FEATURES. so far, so good?
> 
>   but if i check the YP ref manual, i see documentation like this:
> 
> ref-variables.xml:     KERNEL_FEATURES_append_cedartrail +=
> "bsp/cedartrail/cedartrail-pvr-merge.scc" ref-variables.xml:    
> KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc" ref-variables.xml:  
>   KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
> 
> which looks a bit weird -- combining "_append" with "+=" (and even
> inconsistently adding that leading space).
> 
>   is there some difference between the above approaches i've never
> understood? is there a preferred style?

IMO, '..._append +=' shouldn't be used. It might be assumed that the += 
accomplishes more than just adding a leading space, which it doesn't. It's 
much simpler to just include the leading space in the value.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre