From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.windriver.com ([147.11.1.11]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SDHZf-0003TB-TI for openembedded-core@lists.openembedded.org; Thu, 29 Mar 2012 17:47:44 +0200 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca [147.11.189.40]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id q2TFcdfQ003528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Mar 2012 08:38:39 -0700 (PDT) Received: from msp-dhcp10.wrs.com (172.25.34.10) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.1.255.0; Thu, 29 Mar 2012 08:38:40 -0700 Message-ID: <4F7481FE.3020505@windriver.com> Date: Thu, 29 Mar 2012 10:38:38 -0500 From: Mark Hatle Organization: Wind River Systems User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <1332877869-12195-1-git-send-email-kergoth@gmail.com> <1332877869-12195-3-git-send-email-kergoth@gmail.com> <4F72219A.2020301@windriver.com> <4F723618.6060104@windriver.com> <4F723B78.2060308@windriver.com> In-Reply-To: Subject: Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:47:44 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 3/28/12 11:54 PM, Chris Larson wrote: > On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 > wrote: >> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson 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-, 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- 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. Hopefully I'll have an update later today. --Mark