From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ob0-f175.google.com ([209.85.214.175]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SCeXS-0001aK-06 for openembedded-core@lists.openembedded.org; Wed, 28 Mar 2012 00:06:50 +0200 Received: by obqv19 with SMTP id v19so452063obq.6 for ; Tue, 27 Mar 2012 14:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=fJe3t+ubBeD3RTlr7yZV/ZWs8H6Uae2VlZlt9aP0vu4=; b=iyKjZm7ygS69QtugQHYJQc9hkNGeARpf0xysS9ifEz9VQ0aop7NZTh7jiMDfWcBPHH zUwECmzz0IXbtnHjqQSQa6DbDx6PaKVph5hVLBuXxfBMpJqZPzGUXxGFtoVXYrnwXnrB q5R2vVCmDc4gTl8DEn5XGNRnaluGfuVlyqDmKrfiV6UcKI1qy0Ir7rnBcUr7p0yd202O pEhWKcYyXAsZwdKHxSLg1hOGhqCiqcEsAC1gOy2IGU0X/EYLyPhurDBG3SmahfvFKSGR Vo7KUdS0m0cn0ZTjIPEeIbyICbtGF9xh0QE7ABTmjHhCA6p+9m00nNLGuqaAIJ4xi1hI z4oQ== Received: by 10.182.113.106 with SMTP id ix10mr34282512obb.26.1332885467986; Tue, 27 Mar 2012 14:57:47 -0700 (PDT) Received: from frey (ip68-110-79-242.ph.ph.cox.net. [68.110.79.242]) by mx.google.com with ESMTPS id il8sm1109511obc.18.2012.03.27.14.57.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 14:57:47 -0700 (PDT) Date: Tue, 27 Mar 2012 14:57:44 -0700 From: Christopher Larson To: Patches and discussions about the oe-core layer Message-ID: In-Reply-To: <4F723618.6060104@windriver.com> 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> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 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: Tue, 27 Mar 2012 22:06:50 -0000 Content-Type: multipart/alternative; boundary="4f7237d8_419ac241_13b26" --4f7237d8_419ac241_13b26 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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- obeyed, which was the behavior prior to my submitting a patch which removed the explicit TUNE_PKGARCH override in arch-powerpc.inc. 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- 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- definitions for the generic tunings also. -Chris --4f7237d8_419ac241_13b26 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On T= uesday, March 27, 2012 at 2:50 PM, Mark Hatle wrote:
On 3/27/12 4:05 PM, Chris L= arson wrote:

On PowerPC TUNE=5FPKGARCH sho= uld be set to powerpc (or overriden by the machines).
On PowerP= C64, it should be set to powerpc64. If this is not happening that is
the bug, lack of the default TUNE=5FPKGARCH. (based on the original= implementation.)

<= div>I don't think your point of view is covering all the issues. 

The default TUNE=5FPKGARCH is TUNE=5FPKGARCH=5F=24= =7BTUNE=5FPKGARCH=5Ftune-=24=7BDE=46AULTTUNE=7D. If arch-powerpc.inc sets= TUNE=5FPKGARCH directly, as it used to, then all the more specific tunin= gs won't have their TUNE=5FPKGARCH=5Ftune-<tune> obeyed, which was = the behavior prior to my submitting a patch which removed the explicit TU= NE=5FPKGARCH override in arch-powerpc.inc.

So we= have two options. Either we override TUNE=5FPKGARCH directly in arch-pow= erpc.inc again, thereby making powerpc tune- files like tune-ppce500v2 no= t have their TUNE=5FPKGARCH=5Ftune-<tune> obeyed (or those tune- fi= les have to override TUNE=5FPKGARCH as well, which seems counter to the w= hole design of the tuning implementation), or we add TUNE=5FPKGARCH=5Ftun= e-<tune> definitions for the generic tunings also.

-Chris
--4f7237d8_419ac241_13b26--