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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
