On Thu, Mar 29, 2012 at 8:38 AM, Mark Hatle <[email protected]> wrote: > On 3/28/12 11:54 PM, Chris Larson wrote: >> >> On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 >> <[email protected]> wrote: >>> >>> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson<[email protected]> >>> wrote: >>>>> >>>>> 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. >>> >>> >>> If no one else has complained so far it makes me believe they are not >>> missing any TUNE_PKGARCH_tune-<tune> then. >> >> >> I don't understand the point you're attempting to make here. > > > Just an FYI -- I've not forgotten about this.. I'm going to look into what > is currently implemented and figure out how to get it to be consistent.. > things have definitely changed since the initial implementation, and things > are no longer consistent.
Understood, thanks. It's good that someone with a better grasp of the entirety of the implementation and its goals take that on. This particular patch isn't particularly important to me, the other two were, but I'm very curious as to how you'll address this, since as I mentioned before it seems that the non-override based implementation is a problem for archs that explicitly set TUNE_PKGARCH. Thanks for looking into this. -- Christopher Larson _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
