From: Phil Blundell <philb@gnu.org>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Date: Fri, 28 Sep 2012 12:02:50 +0100 [thread overview]
Message-ID: <1348830171.32611.47.camel@phil-desktop> (raw)
In-Reply-To: <5064A1DB.40506@windriver.com>
On Thu, 2012-09-27 at 13:58 -0500, Mark Hatle wrote:
> I've been an advocate for a while that the processor optimization (CCARGS) does
> make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to do
> this. It allows each tune to set something to tell people what that binary is
> really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
I think we've discussed this before but, just to reiterate, this sort of
thing is a matter of DISTRO policy. It is perfectly legitimate to want
to build binaries with, say, -march=armv5te -mtune=arm926ej-s and have
them end up with PACKAGE_ARCH="armv5te" or even just "arm".
It seems to me that we are in danger of adding a lot of complicated and
hard-to-understand machinery to oe-core in an attempt to solve a problem
that ought to be getting solved by the DISTRO, and that by doing so we
might be making life harder rather than easier for DISTROs which happen
to want a slightly different labelling model to the default.
p.
next prev parent reply other threads:[~2012-09-28 11:15 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-22 16:51 [RFC 0/5] OPTDEFAULTTUNE for arm tune files Martin Jansa
2012-09-22 16:51 ` [RFC 1/5] arch-arm: add ARMPKGSFX_CPU to TUNE_PKGARCH because we're using different TUNE_CCARGS Martin Jansa
2012-09-22 16:51 ` [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default Martin Jansa
2012-09-22 17:45 ` Richard Purdie
2012-09-27 8:37 ` Martin Jansa
2012-09-27 18:58 ` Mark Hatle
2012-09-27 19:12 ` Martin Jansa
2012-09-27 19:18 ` Mark Hatle
2012-09-27 19:40 ` Martin Jansa
2012-09-27 19:53 ` Mark Hatle
2012-09-27 20:16 ` Martin Jansa
2012-09-28 11:02 ` Phil Blundell [this message]
2012-09-28 18:21 ` Martin Jansa
2012-10-02 18:43 ` Martin Jansa
2012-10-02 20:36 ` Mark Hatle
2012-10-02 20:38 ` Martin Jansa
2012-10-02 20:47 ` Mark Hatle
2012-09-22 16:51 ` [RFC 3/5] optimized-tune.inc: add optional distro include Martin Jansa
2012-09-22 16:51 ` [RFC 4/5] bitbake.conf: add TUNE_CCARGS[vardepvalue] Martin Jansa
2012-09-22 16:51 ` [RFC 5/5] tune-xscale, tune-arm926ejs: drop ARMPKGSFX_CPU, change ARMPKGARCH instead Martin Jansa
2012-10-04 13:23 ` [PATCH 0/7] conf/machine: fix arm tune files Martin Jansa
2012-10-04 13:23 ` [PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES Martin Jansa
2012-10-04 16:55 ` Khem Raj
2012-10-04 17:13 ` Martin Jansa
2012-10-04 13:23 ` [PATCH 2/7] bitbake.conf: add TUNE_CCARGS[vardepvalue] Martin Jansa
2012-10-04 13:23 ` [PATCH 3/7] tune-cortexr4: fix march value Martin Jansa
2012-10-04 16:55 ` Khem Raj
2012-10-04 13:23 ` [PATCH 4/7] arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes Martin Jansa
2012-10-04 13:23 ` [PATCH 5/7] arch-arm: define different ARMPKGARCH when different CCARGS are used Martin Jansa
2012-10-04 13:23 ` [PATCH 6/7] tune-*: define more generic DEFAULTTUNE to share feed between machines Martin Jansa
2012-10-04 13:23 ` [PATCH 7/7] scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs Martin Jansa
2012-12-04 12:07 ` [PATCHv2] " Martin Jansa
2012-12-04 13:03 ` Richard Purdie
2012-12-04 15:24 ` [PATCHv3] " Martin Jansa
2012-12-04 15:26 ` [PATCHv4] scripts/sstate-diff-machines.sh: " Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1348830171.32611.47.camel@phil-desktop \
--to=philb@gnu.org \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.