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

[Mark Hatle <mark.hatle@windriver.com>]

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.

> 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.

--Mark

> -Chris
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core