Re: Add basic PowerPC core tune config (bug?)

[Phil Blundell <philb@gnu.org>]

On Thu, 2011-07-28 at 10:57 +0200, Koen Kooi wrote:
> Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
> 
> > On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
> >> Saul Wold wrote on 2011-07-28:
> >>> On 07/27/2011 10:25 PM, Kumar Gala wrote:
> >>>> For some reason when I get to do_rootfs for core-image-sato when using
> >>>> rpms I run into an issue in that:
> >>>> 
> >>>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> >>>> 
> >>>> Isn't expanding or taking the assignment in
> >>>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
> >>>> found in meta/conf/bitbake.conf
> >>> 
> >>> I believe that I am seeing this also with an atom-pc build, where the
> >>> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
> >>> list of ARCHS that includes core2 (which atom-pc should be).
> >> 
> >> Hi, I'm suffering from the exactly same issue... :-(
> >> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
> >> yet.
> > 
> > It seems to me that ??= gets confused because the variable name needs 
> > expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
> > PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I 
> > don't know if that indicates a BitBake bug or whether we should try to work 
> > around it.
> 
> I think it has to do with when the anonymous python runs. Try comparing 'bitbake -e' and and 'bitbake -e some-image':
> 
> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep PACKAGE_EXTRA_ARCHS\=
> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> PACKAGE_EXTRA_ARCHS="arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon"
> 
> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> PACKAGE_EXTRA_ARCHS="arm"

No, I think Paul is right about the cause (though I don't agree with him
that it is a bug exactly).  The timing of anonymous python oughtn't to
be different in those two cases so I don't think that will be making a
difference.

That assignment to PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in
bitbake.conf is just fundamentally bogus.  As far as the bitbake parser
is concerned, PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} and
PACKAGE_EXTRA_ARCHS_tune-arm926ejs are different variables (assuming
DEFAULTTUNE=arm926ejs for the sake of an example) and it will create
both of them.  Then, later, when the lvalues get expanded the latter
will be overwritten by the former which seems like it is exactly the
opposite to the effect that's wanted here.

This is long-standing bitbake behaviour and I'm not sure it would be
practical to change.  I think the metadata just needs to be written to
work with the semantics that we have.

p.