On Tue, Mar 27, 2012 at 3:13 PM, Mark Hatle <[email protected]> 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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
