[OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf

[Chris Larson]

On Tue, Mar 27, 2012 at 3:13 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
> On 3/27/12 4:57 PM, Christopher Larson wrote:
>>
>> On Tuesday, March 27, 2012 at 2:50 PM, Mark Hatle wrote:
>>>
>>> On 3/27/12 4:05 PM, Chris Larson wrote:
>>>
>>> On PowerPC TUNE_PKGARCH should be set to powerpc (or overriden by the
>>> machines).
>>> On PowerPC64, it should be set to powerpc64. If this is not happening
>>> that is
>>> the bug, lack of the default TUNE_PKGARCH. (based on the original
>>> implementation.)
>>
>>
>> I don't think your point of view is covering all the issues.
>>
>> The default TUNE_PKGARCH is
>> TUNE_PKGARCH_${TUNE_PKGARCH_tune-${DEFAULTTUNE}. If
>> arch-powerpc.inc sets TUNE_PKGARCH directly, as it used to, then all the
>> more
>> specific tunings won't have their TUNE_PKGARCH_tune-<tune> obeyed, which
>> was the
>> behavior prior to my submitting a patch which removed the explicit
>> TUNE_PKGARCH
>> override in arch-powerpc.inc.
>
>
> TUNE_PKGARCH_[override] should always replace TUNE_PKGARCH shouldn't it?
>  Why isn't the override being obeyed is my issue.  I really don't care much
> about the implementation other then originally I was told not to do that
> during various reviews.. and that the tuning (override) would always replace
> TUNE_PKGARCH.

No, it isn't an override. The way it obeys is through default values
in bitbake.conf. As arch-powerpc.inc would override that default
value, it would no longer obey it. To do what you want, you'd have to
rework how the tune-<tune> specific values are applied in the
implementation.

>> So we have two options. Either we override TUNE_PKGARCH directly in
>> arch-powerpc.inc again, thereby making powerpc tune- files like
>> tune-ppce500v2
>> not have their TUNE_PKGARCH_tune-<tune> obeyed (or those tune- files have
>> to
>> override TUNE_PKGARCH as well, which seems counter to the whole design of
>> the
>> tuning implementation), or we add TUNE_PKGARCH_tune-<tune> definitions for
>> the
>> generic tunings also.
>
>
> We need to be consistent as far as I'm concerned.  If we want to add
> TUNE_PKGARCH_tune-<tune> to all of the tunings, and base architecture
> definitions that is fine.  What I don't want is a mix of different ways this
> stuff is implemented.  It's already complicated enough for people to look at
> and identify what is going on today with subtle differences between the
> files.
>
> If you can explain why the override isn't overriding the default
> TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently
> modify all of the elements... I'm happy to accept the changes to all of the
> tunings.

See above. It's not an override. And plenty of files already specify
TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to
do so for the defaults, personally.
-- 
Christopher Larson