[RFC 0/5] OPTDEFAULTTUNE for arm tune files

[RFC 0/5] OPTDEFAULTTUNE for arm tune files

[Martin Jansa]

This patchset is just RFC because I've modified and tested it only for
tune-arm926ejs and tune-xscale (because I've tried to build qemuarm and
same builddir).

Also I have no strong opinion about used TUNE as suffix (see 1. patch)
or as ARMPKGARCH (see last patch, which reverts most of 1. patch).

And what's even bigger mess are PACKAGE_EXTRA_ARCHS, because to be correct
we should repeat all tune-armv5te variations with xscale prefix/suffix too,
while most people will have only
armv5te and (armv5te-xscale or xscale-te)
current tune files allow also armv4t-xscale etc...

But FWIW with this patchset I can build openssl for qemuarm and qemuarmx,
everything except openssl is shared and built just once and also just once in feed.

qemuarmx is the same like qemuarm but using tune-xscale, see
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/qemu-tests

If we decide this is right way to fix it then it should be extended to all arm tune
files. And also somehow set default DEFAULTTUNE to OPTDEFAULTTUNE if 
PACKAGE_ARCH == MACHINE_ARCH (in this case we know we won't share the feed, so why
use best mtune available).

This allows finer control of which DEFAULTTUNE to use

1) default: don't use mtune, optimize only for march (don't mix mtune in
the same feed).

2) include optimized-tune.inc in distro.conf: use mtune only for some packages, but
with separate package feed for them

3) DEFAULTTUNE = ${OPTDEFAULTTUNE} in distro.conf: always use best mtune
available for MACHINE, but unlike current default, don't mix them in
same package feed

More info in thread:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029414.html

The following changes since commit 5e03d1e83d0536a2fc69a88d3e5407108836203f:

  gcc: Use 4.7.2 release tarball (2012-09-21 14:55:26 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib jansa/tune
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/tune

Martin Jansa (5):
  arch-arm: add ARMPKGSFX_CPU to TUNE_PKGARCH because we're using
    different TUNE_CCARGS
  tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more
    generic DEFAULTTUNE as default
  optimized-tune.inc: add optional distro include
  bitbake.conf: add TUNE_CCARGS[vardepvalue]
  tune-xscale, tune-arm926ejs: drop ARMPKGSFX_CPU, change ARMPKGARCH
    instead

 meta/conf/bitbake.conf                       | 2 ++
 meta/conf/distro/include/optimized-tune.inc  | 2 ++
 meta/conf/machine/include/tune-arm926ejs.inc | 7 ++++---
 meta/conf/machine/include/tune-xscale.inc    | 8 +++++---
 4 files changed, 13 insertions(+), 6 deletions(-)
 create mode 100644 meta/conf/distro/include/optimized-tune.inc

-- 
1.7.12

[RFC 1/5] arch-arm: add ARMPKGSFX_CPU to TUNE_PKGARCH because we're using different TUNE_CCARGS

[Martin Jansa]

* without this tune-xscale and tune-arm926ejs were both creating
  packages in armv5te feed, but each with different -mtune, with
  OEBasicHash enabled it was causing each package to rebuild with new
  -mtune after MACHINE switch, but that doesn't make sense with output
  stored in the same armv5te feed

* this makes different feed for each -mtune/ARMPKGSFX_CPU

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/machine/include/arm/README         | 5 ++++-
 meta/conf/machine/include/arm/arch-arm.inc   | 4 +++-
 meta/conf/machine/include/tune-arm926ejs.inc | 4 ++--
 meta/conf/machine/include/tune-xscale.inc    | 5 +++--
 4 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/meta/conf/machine/include/arm/README b/meta/conf/machine/include/arm/README
index a1beb75..7e52902 100644
--- a/meta/conf/machine/include/arm/README
+++ b/meta/conf/machine/include/arm/README
@@ -16,7 +16,7 @@ default.  The format must be of the form:
 <armversion>[t][e][hf][b][-vfp][-neon]
 
 TUNE_PKGARCH is defined as:
-${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
+${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU}
 
 ARMPKGARCH - This is the core package arch component specified by each 
 tuning.  This is the primary identifier of a tuning.  Usual values are:
@@ -38,3 +38,6 @@ the core arch-arm.inc file.
 
 ARMPKGSFX_FPU - This is the FPU specific suffix.  The suffix indicates 
 specific FPU optimizations.  'vfp' and 'neon' are both defined.
+
+ARMPKGSFX_CPU - This is the CPU specific suffix.  The suffix indicates
+that specific CPU optimizations were used.
diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
index da51044..6f22c94 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -4,12 +4,14 @@ TUNEVALID[bigendian] = "Enable big-endian mode."
 ARMPKGARCH ??= "arm"
 ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
 ARMPKGSFX_FPU ??= ""
+ARMPKGSFX_CPU ??= ""
+ARMPKGSFX_CPU[vardepvalue] = "${ARMPKGSFX_CPU}"
 ARMPKGSFX_DSP ??= ""
 ARMPKGSFX_EABI ??= ""
 ARMPKGSFX_THUMB ??= ""
 
 TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
-TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
+TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU}"
 
 ABIEXTENSION = "eabi"
 
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 7f2cc4e..c6e5289 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -1,4 +1,5 @@
 DEFAULTTUNE ?= "arm926ejs"
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
@@ -7,5 +8,4 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm92
 
 AVAILTUNES += "arm926ejs"
 TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
-PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
-
+PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-arm926ejs"
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index 80a3683..1f47c44 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,4 +1,5 @@
 DEFAULTTUNE ?= "xscale"
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-xscale", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
@@ -7,11 +8,11 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale",
 
 AVAILTUNES += "xscale"
 TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
-PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-xscale"
 
 AVAILTUNES += "xscale-be"
 TUNE_FEATURES_tune-xscale-be = "${TUNE_FEATURES_tune-armv5teb} xscale bigendian"
-PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
+PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb} armv5teb-xscale"
 
 # webkit-gtk has alignment issues with double instructions on armv5 so
 # disable them here
-- 
1.7.12

[RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
  includes its tune*.inc, but it's easy for DISTRO to say it wants
  OPTDEFAULTTUNE for some packages or always (if they don't want to
  share built packages between xscale and arm926ejs).

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/bitbake.conf                       | 1 +
 meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
 meta/conf/machine/include/tune-xscale.inc    | 3 ++-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
 HOST_AS_ARCH = "${TARGET_AS_ARCH}"
 HOST_EXEEXT = ""
 
+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
 TUNE_ARCH ??= "INVALID"
 TUNE_CCARGS ??= ""
 TUNE_LDARGS ??= ""
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index c6e5289..4406b3c 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -1,4 +1,5 @@
-DEFAULTTUNE ?= "arm926ejs"
+DEFAULTTUNE ?= "armv5te"
+OPTDEFAULTTUNE ?= "arm926ejs"
 ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index 1f47c44..a04a5e1 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,4 +1,5 @@
-DEFAULTTUNE ?= "xscale"
+DEFAULTTUNE ?= "armv5te"
+OPTDEFAULTTUNE ?= "xscale"
 ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-xscale", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
-- 
1.7.12

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Richard Purdie]

On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> * this way xscale or arm926ejs is not used by default when some machine
>   includes its tune*.inc, but it's easy for DISTRO to say it wants
>   OPTDEFAULTTUNE for some packages or always (if they don't want to
>   share built packages between xscale and arm926ejs).
> 
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
>  meta/conf/bitbake.conf                       | 1 +
>  meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
>  meta/conf/machine/include/tune-xscale.inc    | 3 ++-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 9b41749..e433fcb 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
>  HOST_AS_ARCH = "${TARGET_AS_ARCH}"
>  HOST_EXEEXT = ""
>  
> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
>  TUNE_ARCH ??= "INVALID"
>  TUNE_CCARGS ??= ""
>  TUNE_LDARGS ??= ""

As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.

I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.

Cheers,

Richard

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> > * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> > * this way xscale or arm926ejs is not used by default when some machine
> >   includes its tune*.inc, but it's easy for DISTRO to say it wants
> >   OPTDEFAULTTUNE for some packages or always (if they don't want to
> >   share built packages between xscale and arm926ejs).
> > 
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> >  meta/conf/bitbake.conf                       | 1 +
> >  meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >  meta/conf/machine/include/tune-xscale.inc    | 3 ++-
> >  3 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 9b41749..e433fcb 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >  HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >  HOST_EXEEXT = ""
> >  
> > +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >  TUNE_ARCH ??= "INVALID"
> >  TUNE_CCARGS ??= ""
> >  TUNE_LDARGS ??= ""
> 
> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> or in meaning and we need to find a better solution. I'm therefore not
> keen on this change.

OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?
 
> I also still think this is a distro packaging issue and should be solved
> by the distro, even if that means more complexity there. That is the
> right place for this particular complexity IMO. I'm happy to support
> that from the core but not in something as user visible and confusing as
> this variable.

Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Mark Hatle]

Let me preface this by I have read the patch set.. Martin asked me to comment on 
the items below...

On 9/27/12 3:37 AM, Martin Jansa wrote:
> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
>>> * this way xscale or arm926ejs is not used by default when some machine
>>>    includes its tune*.inc, but it's easy for DISTRO to say it wants
>>>    OPTDEFAULTTUNE for some packages or always (if they don't want to
>>>    share built packages between xscale and arm926ejs).
>>>
>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>> ---
>>>   meta/conf/bitbake.conf                       | 1 +
>>>   meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
>>>   meta/conf/machine/include/tune-xscale.inc    | 3 ++-
>>>   3 files changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>> index 9b41749..e433fcb 100644
>>> --- a/meta/conf/bitbake.conf
>>> +++ b/meta/conf/bitbake.conf
>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
>>>   HOST_AS_ARCH = "${TARGET_AS_ARCH}"
>>>   HOST_EXEEXT = ""
>>>
>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
>>>   TUNE_ARCH ??= "INVALID"
>>>   TUNE_CCARGS ??= ""
>>>   TUNE_LDARGS ??= ""
>>
>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
>> or in meaning and we need to find a better solution. I'm therefore not
>> keen on this change.
>
> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> different PKGARCH for different TUNE_CCARGS?

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.

The only concern I have with that is:

+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", 
"-arm926ejs", "", d)}"

That probably should be a .= instead of just '='.  That way if the user loads 
multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively 
using the overrides would work as well for this.. i.e. 
ARMPKGSFX_CPU_tune-arm926ejs instead...

I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is 
fine as well, and it was designed to be overriden.. but again the .= or 
-tune_... syntax should be used...

Anyway, my point in this is I like having the stuff unique, but we need to be 
sure that you can specify more then one tune file during a build w/o clashes.

>> I also still think this is a distro packaging issue and should be solved
>> by the distro, even if that means more complexity there. That is the
>> right place for this particular complexity IMO. I'm happy to support
>> that from the core but not in something as user visible and confusing as
>> this variable.
>
> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> there will be much worse then when it's defined in tune-* files, because
> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> config) then it could be.

I really don't have a strong opinion on this either way.  I know for the stuff 
I've done in the past (not oe-based) we've just manually configured (the 
equivalent of the distro conf) with the information on the handful of items that 
people wanted optimized the most...  eglibc, openssl, mysql/posgresql... 
otherwise folks don't seem to care, and re-use works fine.

If the list is small (i.e. less then 10 packages) that specifying it via package 
specific overrides in the distro file should be fine.. if it's more then 10 
(typically) then we need to start looking for another approach.

I'd almost suggest in the distro file you could do:

OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or 
elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.

DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"

and then everything can be encapsulated into the distro file (and distro BSPs). 
  The downside of this approach is that it's not the 'standard' implementation.

--Mark

> Cheers,
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 6258 bytes --]

On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> Let me preface this by I have read the patch set.. Martin asked me to comment on 
> the items below...
> 
> On 9/27/12 3:37 AM, Martin Jansa wrote:
> > On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>> * this way xscale or arm926ejs is not used by default when some machine
> >>>    includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>    OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>    share built packages between xscale and arm926ejs).
> >>>
> >>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>> ---
> >>>   meta/conf/bitbake.conf                       | 1 +
> >>>   meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>   meta/conf/machine/include/tune-xscale.inc    | 3 ++-
> >>>   3 files changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>> index 9b41749..e433fcb 100644
> >>> --- a/meta/conf/bitbake.conf
> >>> +++ b/meta/conf/bitbake.conf
> >>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>   HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>   HOST_EXEEXT = ""
> >>>
> >>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>   TUNE_ARCH ??= "INVALID"
> >>>   TUNE_CCARGS ??= ""
> >>>   TUNE_LDARGS ??= ""
> >>
> >> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >> or in meaning and we need to find a better solution. I'm therefore not
> >> keen on this change.
> >
> > OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> > different PKGARCH for different TUNE_CCARGS?
> 
> 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.
> 
> The only concern I have with that is:
> 
> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", 
> "-arm926ejs", "", d)}"
> 
> That probably should be a .= instead of just '='.  That way if the user loads 
> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively 
> using the overrides would work as well for this.. i.e. 
> ARMPKGSFX_CPU_tune-arm926ejs instead...

OK.

> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is 
> fine as well, and it was designed to be overriden.. but again the .= or 
> -tune_... syntax should be used...

I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.

But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
armv4t-xscale?

Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
would try to download many feeds but only a few does exist).

> Anyway, my point in this is I like having the stuff unique, but we need to be 
> sure that you can specify more then one tune file during a build w/o clashes.
> 
> >> I also still think this is a distro packaging issue and should be solved
> >> by the distro, even if that means more complexity there. That is the
> >> right place for this particular complexity IMO. I'm happy to support
> >> that from the core but not in something as user visible and confusing as
> >> this variable.
> >
> > Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> > there will be much worse then when it's defined in tune-* files, because
> > now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> > TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> > config) then it could be.
> 
> I really don't have a strong opinion on this either way.  I know for the stuff 
> I've done in the past (not oe-based) we've just manually configured (the 
> equivalent of the distro conf) with the information on the handful of items that 
> people wanted optimized the most...  eglibc, openssl, mysql/posgresql... 
> otherwise folks don't seem to care, and re-use works fine.
> 
> If the list is small (i.e. less then 10 packages) that specifying it via package 
> specific overrides in the distro file should be fine.. if it's more then 10 
> (typically) then we need to start looking for another approach.
> 
> I'd almost suggest in the distro file you could do:
> 
> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or 
> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> 
> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"

Yes but first I have to say:
DEFAULTTUNE_spitz = armv5te
OPTDEFAULTTUNE_spitz = xscale
DEFAULTTUNE_qemuarm = armv5te
OPTDEFAULTTUNE_qemuarm = arm926ejs
or
DEFAULTTUNE_tune-xscale = armv5te
OPTDEFAULTTUNE_tun_xscale = xscale
DEFAULTTUNE_tune-arm926ejs = armv5te
OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs

to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's
not in defined tune-xscale/tune-arm926ejs.

And that's what I didn't want to include in my distro config (and then
explaining to someone that when adding MACHINE foo he has to send patch
for distro config).

Cheers,

> and then everything can be encapsulated into the distro file (and distro BSPs). 
>   The downside of this approach is that it's not the 'standard' implementation.
> 
> --Mark
> 
> > Cheers,
> >
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Mark Hatle]

On 9/27/12 2:12 PM, Martin Jansa wrote:
> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
>> Let me preface this by I have read the patch set.. Martin asked me to comment on
>> the items below...
>>
>> On 9/27/12 3:37 AM, Martin Jansa wrote:
>>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
>>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
>>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
>>>>> * this way xscale or arm926ejs is not used by default when some machine
>>>>>     includes its tune*.inc, but it's easy for DISTRO to say it wants
>>>>>     OPTDEFAULTTUNE for some packages or always (if they don't want to
>>>>>     share built packages between xscale and arm926ejs).
>>>>>
>>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>>>> ---
>>>>>    meta/conf/bitbake.conf                       | 1 +
>>>>>    meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
>>>>>    meta/conf/machine/include/tune-xscale.inc    | 3 ++-
>>>>>    3 files changed, 5 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>>>> index 9b41749..e433fcb 100644
>>>>> --- a/meta/conf/bitbake.conf
>>>>> +++ b/meta/conf/bitbake.conf
>>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
>>>>>    HOST_AS_ARCH = "${TARGET_AS_ARCH}"
>>>>>    HOST_EXEEXT = ""
>>>>>
>>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
>>>>>    TUNE_ARCH ??= "INVALID"
>>>>>    TUNE_CCARGS ??= ""
>>>>>    TUNE_LDARGS ??= ""
>>>>
>>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
>>>> or in meaning and we need to find a better solution. I'm therefore not
>>>> keen on this change.
>>>
>>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
>>> different PKGARCH for different TUNE_CCARGS?
>>
>> 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.
>>
>> The only concern I have with that is:
>>
>> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
>> "-arm926ejs", "", d)}"
>>
>> That probably should be a .= instead of just '='.  That way if the user loads
>> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
>> using the overrides would work as well for this.. i.e.
>> ARMPKGSFX_CPU_tune-arm926ejs instead...
>
> OK.
>
>> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
>> fine as well, and it was designed to be overriden.. but again the .= or
>> -tune_... syntax should be used...
>
> I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
>
> But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
> PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
> armv4t-xscale?
>
> Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
> would try to download many feeds but only a few does exist).

The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. 
Which of course feed into the list of feeds used by the various packaging 
systems.  I think it's up to the distribution to modify or limit the feeds 
resolved, but I don't know if there is a clean way to do this.  I always error 
on listing more then less, because I don't know how people are going to want to 
mix and match things.  (And a BSP or end user can always just define what the 
PACKAGE_EXTRA_ARCHS value should be.)

>> Anyway, my point in this is I like having the stuff unique, but we need to be
>> sure that you can specify more then one tune file during a build w/o clashes.
>>
>>>> I also still think this is a distro packaging issue and should be solved
>>>> by the distro, even if that means more complexity there. That is the
>>>> right place for this particular complexity IMO. I'm happy to support
>>>> that from the core but not in something as user visible and confusing as
>>>> this variable.
>>>
>>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
>>> there will be much worse then when it's defined in tune-* files, because
>>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
>>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
>>> config) then it could be.
>>
>> I really don't have a strong opinion on this either way.  I know for the stuff
>> I've done in the past (not oe-based) we've just manually configured (the
>> equivalent of the distro conf) with the information on the handful of items that
>> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
>> otherwise folks don't seem to care, and re-use works fine.
>>
>> If the list is small (i.e. less then 10 packages) that specifying it via package
>> specific overrides in the distro file should be fine.. if it's more then 10
>> (typically) then we need to start looking for another approach.
>>
>> I'd almost suggest in the distro file you could do:
>>
>> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
>> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
>>
>> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
>
> Yes but first I have to say:
> DEFAULTTUNE_spitz = armv5te
> OPTDEFAULTTUNE_spitz = xscale
> DEFAULTTUNE_qemuarm = armv5te
> OPTDEFAULTTUNE_qemuarm = arm926ejs
> or
> DEFAULTTUNE_tune-xscale = armv5te
> OPTDEFAULTTUNE_tun_xscale = xscale
> DEFAULTTUNE_tune-arm926ejs = armv5te
> OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
>
> to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's
> not in defined tune-xscale/tune-arm926ejs.

I assume that a distribution will be (bb)appending, or defining their own BSPs. 
  And in that case it's pretty easy to add both the DEFAULTTUNE and 
OPTDEFAULTTUNE line to the BSP configuration file.  (And if someone uses a 
different distribution, then the DEFAULT is used as that is the standard method.)

> And that's what I didn't want to include in my distro config (and then
> explaining to someone that when adding MACHINE foo he has to send patch
> for distro config).

Ya I understand.  This is an odd situation for many embedded systems.  You want 
to reuse packages that aren't optimally tuned -- but you still want a few tuned 
packages.  It's certainly a usecase we need to support -- but I'm not sure in 
the end how people end up doing this.

I know most of my commercial customers just want everything to be tuned for the 
target BSP.. and they build new distributions for each product they implement.

--Mark

> Cheers,
>
>> and then everything can be encapsulated into the distro file (and distro BSPs).
>>    The downside of this approach is that it's not the 'standard' implementation.
>>
>> --Mark
>>
>>> Cheers,
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 8160 bytes --]

On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:
> On 9/27/12 2:12 PM, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> >> Let me preface this by I have read the patch set.. Martin asked me to comment on
> >> the items below...
> >>
> >> On 9/27/12 3:37 AM, Martin Jansa wrote:
> >>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>>>> * this way xscale or arm926ejs is not used by default when some machine
> >>>>>     includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>>>     OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>>>     share built packages between xscale and arm926ejs).
> >>>>>
> >>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>>>> ---
> >>>>>    meta/conf/bitbake.conf                       | 1 +
> >>>>>    meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>>>    meta/conf/machine/include/tune-xscale.inc    | 3 ++-
> >>>>>    3 files changed, 5 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>>>> index 9b41749..e433fcb 100644
> >>>>> --- a/meta/conf/bitbake.conf
> >>>>> +++ b/meta/conf/bitbake.conf
> >>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>>>    HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>>>    HOST_EXEEXT = ""
> >>>>>
> >>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>>>    TUNE_ARCH ??= "INVALID"
> >>>>>    TUNE_CCARGS ??= ""
> >>>>>    TUNE_LDARGS ??= ""
> >>>>
> >>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >>>> or in meaning and we need to find a better solution. I'm therefore not
> >>>> keen on this change.
> >>>
> >>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> >>> different PKGARCH for different TUNE_CCARGS?
> >>
> >> 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.
> >>
> >> The only concern I have with that is:
> >>
> >> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
> >> "-arm926ejs", "", d)}"
> >>
> >> That probably should be a .= instead of just '='.  That way if the user loads
> >> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
> >> using the overrides would work as well for this.. i.e.
> >> ARMPKGSFX_CPU_tune-arm926ejs instead...
> >
> > OK.
> >
> >> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
> >> fine as well, and it was designed to be overriden.. but again the .= or
> >> -tune_... syntax should be used...
> >
> > I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
> >
> > But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
> > PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> > do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
> > armv4t-xscale?
> >
> > Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
> > would try to download many feeds but only a few does exist).
> 
> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. 
> Which of course feed into the list of feeds used by the various packaging 
> systems.  I think it's up to the distribution to modify or limit the feeds 
> resolved, but I don't know if there is a clean way to do this.  I always error 
> on listing more then less, because I don't know how people are going to want to 
> mix and match things.  (And a BSP or end user can always just define what the 
> PACKAGE_EXTRA_ARCHS value should be.)

Yes that's what I do now, but I'm not too happy about it :/
SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86"
SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"

> >> Anyway, my point in this is I like having the stuff unique, but we need to be
> >> sure that you can specify more then one tune file during a build w/o clashes.
> >>
> >>>> I also still think this is a distro packaging issue and should be solved
> >>>> by the distro, even if that means more complexity there. That is the
> >>>> right place for this particular complexity IMO. I'm happy to support
> >>>> that from the core but not in something as user visible and confusing as
> >>>> this variable.
> >>>
> >>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> >>> there will be much worse then when it's defined in tune-* files, because
> >>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> >>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> >>> config) then it could be.
> >>
> >> I really don't have a strong opinion on this either way.  I know for the stuff
> >> I've done in the past (not oe-based) we've just manually configured (the
> >> equivalent of the distro conf) with the information on the handful of items that
> >> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
> >> otherwise folks don't seem to care, and re-use works fine.
> >>
> >> If the list is small (i.e. less then 10 packages) that specifying it via package
> >> specific overrides in the distro file should be fine.. if it's more then 10
> >> (typically) then we need to start looking for another approach.
> >>
> >> I'd almost suggest in the distro file you could do:
> >>
> >> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
> >> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> >>
> >> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
> >
> > Yes but first I have to say:
> > DEFAULTTUNE_spitz = armv5te
> > OPTDEFAULTTUNE_spitz = xscale
> > DEFAULTTUNE_qemuarm = armv5te
> > OPTDEFAULTTUNE_qemuarm = arm926ejs
> > or
> > DEFAULTTUNE_tune-xscale = armv5te
> > OPTDEFAULTTUNE_tun_xscale = xscale
> > DEFAULTTUNE_tune-arm926ejs = armv5te
> > OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
> >
> > to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's
> > not in defined tune-xscale/tune-arm926ejs.
> 
> I assume that a distribution will be (bb)appending, or defining their own BSPs. 
>   And in that case it's pretty easy to add both the DEFAULTTUNE and 
> OPTDEFAULTTUNE line to the BSP configuration file.  (And if someone uses a 
> different distribution, then the DEFAULT is used as that is the standard method.)

Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in
oe-core? 

Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE
then everybody else (who is interested in my BSP but has own distro)
needs to agree on name OPTDEFAULTTUNE.

That's why I wanted this defined in tune-* files which are shared in
oe-core and used by everybody I guess.

> > And that's what I didn't want to include in my distro config (and then
> > explaining to someone that when adding MACHINE foo he has to send patch
> > for distro config).
> 
> Ya I understand.  This is an odd situation for many embedded systems.  You want 
> to reuse packages that aren't optimally tuned -- but you still want a few tuned 
> packages.  It's certainly a usecase we need to support -- but I'm not sure in 
> the end how people end up doing this.
> 
> I know most of my commercial customers just want everything to be tuned for the 
> target BSP.. and they build new distributions for each product they implement.

Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both
use cases to coexist without any complex configuration on distro side.

Thanks again for constructive comment.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Mark Hatle]

On 9/27/12 2:40 PM, Martin Jansa wrote:
> On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:
>> On 9/27/12 2:12 PM, Martin Jansa wrote:
>>> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
>>>> Let me preface this by I have read the patch set.. Martin asked me to comment on
>>>> the items below...
>>>>
>>>> On 9/27/12 3:37 AM, Martin Jansa wrote:
>>>>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
>>>>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
>>>>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
>>>>>>> * this way xscale or arm926ejs is not used by default when some machine
>>>>>>>      includes its tune*.inc, but it's easy for DISTRO to say it wants
>>>>>>>      OPTDEFAULTTUNE for some packages or always (if they don't want to
>>>>>>>      share built packages between xscale and arm926ejs).
>>>>>>>
>>>>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>>>>>> ---
>>>>>>>     meta/conf/bitbake.conf                       | 1 +
>>>>>>>     meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
>>>>>>>     meta/conf/machine/include/tune-xscale.inc    | 3 ++-
>>>>>>>     3 files changed, 5 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>>>>>> index 9b41749..e433fcb 100644
>>>>>>> --- a/meta/conf/bitbake.conf
>>>>>>> +++ b/meta/conf/bitbake.conf
>>>>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
>>>>>>>     HOST_AS_ARCH = "${TARGET_AS_ARCH}"
>>>>>>>     HOST_EXEEXT = ""
>>>>>>>
>>>>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
>>>>>>>     TUNE_ARCH ??= "INVALID"
>>>>>>>     TUNE_CCARGS ??= ""
>>>>>>>     TUNE_LDARGS ??= ""
>>>>>>
>>>>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
>>>>>> or in meaning and we need to find a better solution. I'm therefore not
>>>>>> keen on this change.
>>>>>
>>>>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
>>>>> different PKGARCH for different TUNE_CCARGS?
>>>>
>>>> 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.
>>>>
>>>> The only concern I have with that is:
>>>>
>>>> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
>>>> "-arm926ejs", "", d)}"
>>>>
>>>> That probably should be a .= instead of just '='.  That way if the user loads
>>>> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
>>>> using the overrides would work as well for this.. i.e.
>>>> ARMPKGSFX_CPU_tune-arm926ejs instead...
>>>
>>> OK.
>>>
>>>> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
>>>> fine as well, and it was designed to be overriden.. but again the .= or
>>>> -tune_... syntax should be used...
>>>
>>> I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
>>>
>>> But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
>>> PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>> do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
>>> armv4t-xscale?
>>>
>>> Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
>>> would try to download many feeds but only a few does exist).
>>
>> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names.
>> Which of course feed into the list of feeds used by the various packaging
>> systems.  I think it's up to the distribution to modify or limit the feeds
>> resolved, but I don't know if there is a clean way to do this.  I always error
>> on listing more then less, because I don't know how people are going to want to
>> mix and match things.  (And a BSP or end user can always just define what the
>> PACKAGE_EXTRA_ARCHS value should be.)
>
> Yes that's what I do now, but I'm not too happy about it :/
> SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86"
> SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
> SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"
>
>>>> Anyway, my point in this is I like having the stuff unique, but we need to be
>>>> sure that you can specify more then one tune file during a build w/o clashes.
>>>>
>>>>>> I also still think this is a distro packaging issue and should be solved
>>>>>> by the distro, even if that means more complexity there. That is the
>>>>>> right place for this particular complexity IMO. I'm happy to support
>>>>>> that from the core but not in something as user visible and confusing as
>>>>>> this variable.
>>>>>
>>>>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
>>>>> there will be much worse then when it's defined in tune-* files, because
>>>>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
>>>>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
>>>>> config) then it could be.
>>>>
>>>> I really don't have a strong opinion on this either way.  I know for the stuff
>>>> I've done in the past (not oe-based) we've just manually configured (the
>>>> equivalent of the distro conf) with the information on the handful of items that
>>>> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
>>>> otherwise folks don't seem to care, and re-use works fine.
>>>>
>>>> If the list is small (i.e. less then 10 packages) that specifying it via package
>>>> specific overrides in the distro file should be fine.. if it's more then 10
>>>> (typically) then we need to start looking for another approach.
>>>>
>>>> I'd almost suggest in the distro file you could do:
>>>>
>>>> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
>>>> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
>>>>
>>>> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
>>>
>>> Yes but first I have to say:
>>> DEFAULTTUNE_spitz = armv5te
>>> OPTDEFAULTTUNE_spitz = xscale
>>> DEFAULTTUNE_qemuarm = armv5te
>>> OPTDEFAULTTUNE_qemuarm = arm926ejs
>>> or
>>> DEFAULTTUNE_tune-xscale = armv5te
>>> OPTDEFAULTTUNE_tun_xscale = xscale
>>> DEFAULTTUNE_tune-arm926ejs = armv5te
>>> OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
>>>
>>> to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's
>>> not in defined tune-xscale/tune-arm926ejs.
>>
>> I assume that a distribution will be (bb)appending, or defining their own BSPs.
>>    And in that case it's pretty easy to add both the DEFAULTTUNE and
>> OPTDEFAULTTUNE line to the BSP configuration file.  (And if someone uses a
>> different distribution, then the DEFAULT is used as that is the standard method.)
>
> Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in
> oe-core?

Sorry, not bbappend in this case..  but you can do it in a distribution layer. 
(This is from memory so I might not be 100% correct.)

You should be able to have in your own layer a qemuarm.conf that looks like:

require conf/machine/qemuarm.conf
OPTDEFAULTTUNE = "something"
DEFAULTTUNE = "something_else"

It will know not to open itself in the requires.... and fall back to a previous 
layer.

(If that doesn't work, I know we did it somehow.. since we ran into a similar 
situation with our product.)

> Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE
> then everybody else (who is interested in my BSP but has own distro)
> needs to agree on name OPTDEFAULTTUNE.
>
> That's why I wanted this defined in tune-* files which are shared in
> oe-core and used by everybody I guess.

I agree completely, this is the downside of doing it int he distro files vs the 
tune files.  But in the end it seems reasonable to make it a machine or 
distribution setting of some kind.

>>> And that's what I didn't want to include in my distro config (and then
>>> explaining to someone that when adding MACHINE foo he has to send patch
>>> for distro config).
>>
>> Ya I understand.  This is an odd situation for many embedded systems.  You want
>> to reuse packages that aren't optimally tuned -- but you still want a few tuned
>> packages.  It's certainly a usecase we need to support -- but I'm not sure in
>> the end how people end up doing this.
>>
>> I know most of my commercial customers just want everything to be tuned for the
>> target BSP.. and they build new distributions for each product they implement.
>
> Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both
> use cases to coexist without any complex configuration on distro side.

Yup, no disagreement there.

--Mark

> Thanks again for constructive comment.
>
> Cheers,
>

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 9664 bytes --]

On Thu, Sep 27, 2012 at 02:53:21PM -0500, Mark Hatle wrote:
> On 9/27/12 2:40 PM, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:
> >> On 9/27/12 2:12 PM, Martin Jansa wrote:
> >>> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> >>>> Let me preface this by I have read the patch set.. Martin asked me to comment on
> >>>> the items below...
> >>>>
> >>>> On 9/27/12 3:37 AM, Martin Jansa wrote:
> >>>>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >>>>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>>>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>>>>>> * this way xscale or arm926ejs is not used by default when some machine
> >>>>>>>      includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>>>>>      OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>>>>>      share built packages between xscale and arm926ejs).
> >>>>>>>
> >>>>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>>>>>> ---
> >>>>>>>     meta/conf/bitbake.conf                       | 1 +
> >>>>>>>     meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>>>>>     meta/conf/machine/include/tune-xscale.inc    | 3 ++-
> >>>>>>>     3 files changed, 5 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>>>>>> index 9b41749..e433fcb 100644
> >>>>>>> --- a/meta/conf/bitbake.conf
> >>>>>>> +++ b/meta/conf/bitbake.conf
> >>>>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>>>>>     HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>>>>>     HOST_EXEEXT = ""
> >>>>>>>
> >>>>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>>>>>     TUNE_ARCH ??= "INVALID"
> >>>>>>>     TUNE_CCARGS ??= ""
> >>>>>>>     TUNE_LDARGS ??= ""
> >>>>>>
> >>>>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >>>>>> or in meaning and we need to find a better solution. I'm therefore not
> >>>>>> keen on this change.
> >>>>>
> >>>>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> >>>>> different PKGARCH for different TUNE_CCARGS?
> >>>>
> >>>> 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.
> >>>>
> >>>> The only concern I have with that is:
> >>>>
> >>>> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
> >>>> "-arm926ejs", "", d)}"
> >>>>
> >>>> That probably should be a .= instead of just '='.  That way if the user loads
> >>>> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
> >>>> using the overrides would work as well for this.. i.e.
> >>>> ARMPKGSFX_CPU_tune-arm926ejs instead...
> >>>
> >>> OK.
> >>>
> >>>> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
> >>>> fine as well, and it was designed to be overriden.. but again the .= or
> >>>> -tune_... syntax should be used...
> >>>
> >>> I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
> >>>
> >>> But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
> >>> PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> >>> do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
> >>> armv4t-xscale?
> >>>
> >>> Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
> >>> would try to download many feeds but only a few does exist).
> >>
> >> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names.
> >> Which of course feed into the list of feeds used by the various packaging
> >> systems.  I think it's up to the distribution to modify or limit the feeds
> >> resolved, but I don't know if there is a clean way to do this.  I always error
> >> on listing more then less, because I don't know how people are going to want to
> >> mix and match things.  (And a BSP or end user can always just define what the
> >> PACKAGE_EXTRA_ARCHS value should be.)
> >
> > Yes that's what I do now, but I'm not too happy about it :/
> > SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86"
> > SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
> > SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"
> >
> >>>> Anyway, my point in this is I like having the stuff unique, but we need to be
> >>>> sure that you can specify more then one tune file during a build w/o clashes.
> >>>>
> >>>>>> I also still think this is a distro packaging issue and should be solved
> >>>>>> by the distro, even if that means more complexity there. That is the
> >>>>>> right place for this particular complexity IMO. I'm happy to support
> >>>>>> that from the core but not in something as user visible and confusing as
> >>>>>> this variable.
> >>>>>
> >>>>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> >>>>> there will be much worse then when it's defined in tune-* files, because
> >>>>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> >>>>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> >>>>> config) then it could be.
> >>>>
> >>>> I really don't have a strong opinion on this either way.  I know for the stuff
> >>>> I've done in the past (not oe-based) we've just manually configured (the
> >>>> equivalent of the distro conf) with the information on the handful of items that
> >>>> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
> >>>> otherwise folks don't seem to care, and re-use works fine.
> >>>>
> >>>> If the list is small (i.e. less then 10 packages) that specifying it via package
> >>>> specific overrides in the distro file should be fine.. if it's more then 10
> >>>> (typically) then we need to start looking for another approach.
> >>>>
> >>>> I'd almost suggest in the distro file you could do:
> >>>>
> >>>> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
> >>>> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> >>>>
> >>>> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
> >>>
> >>> Yes but first I have to say:
> >>> DEFAULTTUNE_spitz = armv5te
> >>> OPTDEFAULTTUNE_spitz = xscale
> >>> DEFAULTTUNE_qemuarm = armv5te
> >>> OPTDEFAULTTUNE_qemuarm = arm926ejs
> >>> or
> >>> DEFAULTTUNE_tune-xscale = armv5te
> >>> OPTDEFAULTTUNE_tun_xscale = xscale
> >>> DEFAULTTUNE_tune-arm926ejs = armv5te
> >>> OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
> >>>
> >>> to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's
> >>> not in defined tune-xscale/tune-arm926ejs.
> >>
> >> I assume that a distribution will be (bb)appending, or defining their own BSPs.
> >>    And in that case it's pretty easy to add both the DEFAULTTUNE and
> >> OPTDEFAULTTUNE line to the BSP configuration file.  (And if someone uses a
> >> different distribution, then the DEFAULT is used as that is the standard method.)
> >
> > Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in
> > oe-core?
> 
> Sorry, not bbappend in this case..  but you can do it in a distribution layer. 
> (This is from memory so I might not be 100% correct.)
> 
> You should be able to have in your own layer a qemuarm.conf that looks like:
> 
> require conf/machine/qemuarm.conf
> OPTDEFAULTTUNE = "something"
> DEFAULTTUNE = "something_else"
> 
> It will know not to open itself in the requires.... and fall back to a previous 
> layer.
> 
> (If that doesn't work, I know we did it somehow.. since we ran into a similar 
> situation with our product.)

yes but that's still at least 2 more lines (possibly in separate .conf
file) for each MACHINE I could possibly support by my distro, I would like 
to keep it more universal (or ortogonal in distro/machine/image sense).

> > Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE
> > then everybody else (who is interested in my BSP but has own distro)
> > needs to agree on name OPTDEFAULTTUNE.
> >
> > That's why I wanted this defined in tune-* files which are shared in
> > oe-core and used by everybody I guess.
> 
> I agree completely, this is the downside of doing it int he distro files vs the 
> tune files.  But in the end it seems reasonable to make it a machine or 
> distribution setting of some kind.
>
> >>> And that's what I didn't want to include in my distro config (and then
> >>> explaining to someone that when adding MACHINE foo he has to send patch
> >>> for distro config).
> >>
> >> Ya I understand.  This is an odd situation for many embedded systems.  You want
> >> to reuse packages that aren't optimally tuned -- but you still want a few tuned
> >> packages.  It's certainly a usecase we need to support -- but I'm not sure in
> >> the end how people end up doing this.
> >>
> >> I know most of my commercial customers just want everything to be tuned for the
> >> target BSP.. and they build new distributions for each product they implement.
> >
> > Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both
> > use cases to coexist without any complex configuration on distro side.
> 
> Yup, no disagreement there.

Ok, lets see if this changes RP's view on OPTDEFAULTTUNE.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Phil Blundell]

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.

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Fri, Sep 28, 2012 at 12:02:50PM +0100, Phil Blundell wrote:
> 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.

That's already there with DEFAULTUNE/AVAILTUNES machinery, isn't it?

Having that with better default values doesn't make things worse for
such DISTROs.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5888 bytes --]

On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> Let me preface this by I have read the patch set.. Martin asked me to comment on 
> the items below...
> 
> On 9/27/12 3:37 AM, Martin Jansa wrote:
> > On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>> * this way xscale or arm926ejs is not used by default when some machine
> >>>    includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>    OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>    share built packages between xscale and arm926ejs).
> >>>
> >>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>> ---
> >>>   meta/conf/bitbake.conf                       | 1 +
> >>>   meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>   meta/conf/machine/include/tune-xscale.inc    | 3 ++-
> >>>   3 files changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>> index 9b41749..e433fcb 100644
> >>> --- a/meta/conf/bitbake.conf
> >>> +++ b/meta/conf/bitbake.conf
> >>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>   HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>   HOST_EXEEXT = ""
> >>>
> >>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>   TUNE_ARCH ??= "INVALID"
> >>>   TUNE_CCARGS ??= ""
> >>>   TUNE_LDARGS ??= ""
> >>
> >> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >> or in meaning and we need to find a better solution. I'm therefore not
> >> keen on this change.
> >
> > OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> > different PKGARCH for different TUNE_CCARGS?
> 
> 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.
> 
> The only concern I have with that is:
> 
> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", 
> "-arm926ejs", "", d)}"
> 
> That probably should be a .= instead of just '='.  That way if the user loads 
> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively 
> using the overrides would work as well for this.. i.e. 
> ARMPKGSFX_CPU_tune-arm926ejs instead...
> 
> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is 
> fine as well, and it was designed to be overriden.. but again the .= or 
> -tune_... syntax should be used...

I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test

While changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add 
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).

This makes whole
TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
a bit less usefull, maybe ARMPKGSFX_CPU was better approach..

Cheers,

> 
> Anyway, my point in this is I like having the stuff unique, but we need to be 
> sure that you can specify more then one tune file during a build w/o clashes.
> 
> >> I also still think this is a distro packaging issue and should be solved
> >> by the distro, even if that means more complexity there. That is the
> >> right place for this particular complexity IMO. I'm happy to support
> >> that from the core but not in something as user visible and confusing as
> >> this variable.
> >
> > Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> > there will be much worse then when it's defined in tune-* files, because
> > now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> > TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> > config) then it could be.
> 
> I really don't have a strong opinion on this either way.  I know for the stuff 
> I've done in the past (not oe-based) we've just manually configured (the 
> equivalent of the distro conf) with the information on the handful of items that 
> people wanted optimized the most...  eglibc, openssl, mysql/posgresql... 
> otherwise folks don't seem to care, and re-use works fine.
> 
> If the list is small (i.e. less then 10 packages) that specifying it via package 
> specific overrides in the distro file should be fine.. if it's more then 10 
> (typically) then we need to start looking for another approach.
> 
> I'd almost suggest in the distro file you could do:
> 
> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or 
> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> 
> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
> 
> and then everything can be encapsulated into the distro file (and distro BSPs). 
>   The downside of this approach is that it's not the 'standard' implementation.
> 
> --Mark
> 
> > Cheers,
> >
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Mark Hatle]

On 10/2/12 1:43 PM, Martin Jansa wrote:
> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
>> Let me preface this by I have read the patch set.. Martin asked me to comment on
>> the items below...
>>
>> On 9/27/12 3:37 AM, Martin Jansa wrote:
>>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
>>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
>>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
>>>>> * this way xscale or arm926ejs is not used by default when some machine
>>>>>     includes its tune*.inc, but it's easy for DISTRO to say it wants
>>>>>     OPTDEFAULTTUNE for some packages or always (if they don't want to
>>>>>     share built packages between xscale and arm926ejs).
>>>>>
>>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>>>> ---
>>>>>    meta/conf/bitbake.conf                       | 1 +
>>>>>    meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
>>>>>    meta/conf/machine/include/tune-xscale.inc    | 3 ++-
>>>>>    3 files changed, 5 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>>>> index 9b41749..e433fcb 100644
>>>>> --- a/meta/conf/bitbake.conf
>>>>> +++ b/meta/conf/bitbake.conf
>>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
>>>>>    HOST_AS_ARCH = "${TARGET_AS_ARCH}"
>>>>>    HOST_EXEEXT = ""
>>>>>
>>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
>>>>>    TUNE_ARCH ??= "INVALID"
>>>>>    TUNE_CCARGS ??= ""
>>>>>    TUNE_LDARGS ??= ""
>>>>
>>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
>>>> or in meaning and we need to find a better solution. I'm therefore not
>>>> keen on this change.
>>>
>>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
>>> different PKGARCH for different TUNE_CCARGS?
>>
>> 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.
>>
>> The only concern I have with that is:
>>
>> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
>> "-arm926ejs", "", d)}"
>>
>> That probably should be a .= instead of just '='.  That way if the user loads
>> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
>> using the overrides would work as well for this.. i.e.
>> ARMPKGSFX_CPU_tune-arm926ejs instead...
>>
>> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
>> fine as well, and it was designed to be overriden.. but again the .= or
>> -tune_... syntax should be used...
>
> I've updated contrib/jansa/tune-test with this.
> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
>
> While changing that to use e.g.
> ARMPKGARCH_tune-xscale
> I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
> in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
> arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).
>
> This makes whole
> TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
> a bit less usefull, maybe ARMPKGSFX_CPU was better approach..

I've clarified with RP on this.  Tune values are not a 'true' override because 
of evaluation time of overrides.  We want the DEFAULTTUNE to be changeable 
during the build process to allow multilibs, alternative configurations, etc.

So in the tunes to do override-like implementations, you will need:

ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"

and then in each tune fragment:

ARMPKGARCH_tune-foo = "bar"

--Mark

> Cheers,
>
>>
>> Anyway, my point in this is I like having the stuff unique, but we need to be
>> sure that you can specify more then one tune file during a build w/o clashes.
>>
>>>> I also still think this is a distro packaging issue and should be solved
>>>> by the distro, even if that means more complexity there. That is the
>>>> right place for this particular complexity IMO. I'm happy to support
>>>> that from the core but not in something as user visible and confusing as
>>>> this variable.
>>>
>>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
>>> there will be much worse then when it's defined in tune-* files, because
>>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
>>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
>>> config) then it could be.
>>
>> I really don't have a strong opinion on this either way.  I know for the stuff
>> I've done in the past (not oe-based) we've just manually configured (the
>> equivalent of the distro conf) with the information on the handful of items that
>> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
>> otherwise folks don't seem to care, and re-use works fine.
>>
>> If the list is small (i.e. less then 10 packages) that specifying it via package
>> specific overrides in the distro file should be fine.. if it's more then 10
>> (typically) then we need to start looking for another approach.
>>
>> I'd almost suggest in the distro file you could do:
>>
>> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
>> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
>>
>> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
>>
>> and then everything can be encapsulated into the distro file (and distro BSPs).
>>    The downside of this approach is that it's not the 'standard' implementation.
>>
>> --Mark
>>
>>> Cheers,
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 6880 bytes --]

On Tue, Oct 02, 2012 at 03:36:16PM -0500, Mark Hatle wrote:
> On 10/2/12 1:43 PM, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> >> Let me preface this by I have read the patch set.. Martin asked me to comment on
> >> the items below...
> >>
> >> On 9/27/12 3:37 AM, Martin Jansa wrote:
> >>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>>>> * this way xscale or arm926ejs is not used by default when some machine
> >>>>>     includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>>>     OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>>>     share built packages between xscale and arm926ejs).
> >>>>>
> >>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>>>> ---
> >>>>>    meta/conf/bitbake.conf                       | 1 +
> >>>>>    meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>>>    meta/conf/machine/include/tune-xscale.inc    | 3 ++-
> >>>>>    3 files changed, 5 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>>>> index 9b41749..e433fcb 100644
> >>>>> --- a/meta/conf/bitbake.conf
> >>>>> +++ b/meta/conf/bitbake.conf
> >>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>>>    HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>>>    HOST_EXEEXT = ""
> >>>>>
> >>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>>>    TUNE_ARCH ??= "INVALID"
> >>>>>    TUNE_CCARGS ??= ""
> >>>>>    TUNE_LDARGS ??= ""
> >>>>
> >>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >>>> or in meaning and we need to find a better solution. I'm therefore not
> >>>> keen on this change.
> >>>
> >>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> >>> different PKGARCH for different TUNE_CCARGS?
> >>
> >> 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.
> >>
> >> The only concern I have with that is:
> >>
> >> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
> >> "-arm926ejs", "", d)}"
> >>
> >> That probably should be a .= instead of just '='.  That way if the user loads
> >> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
> >> using the overrides would work as well for this.. i.e.
> >> ARMPKGSFX_CPU_tune-arm926ejs instead...
> >>
> >> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
> >> fine as well, and it was designed to be overriden.. but again the .= or
> >> -tune_... syntax should be used...
> >
> > I've updated contrib/jansa/tune-test with this.
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
> >
> > While changing that to use e.g.
> > ARMPKGARCH_tune-xscale
> > I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
> > ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
> > in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
> > arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).
> >
> > This makes whole
> > TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
> > a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
> 
> I've clarified with RP on this.  Tune values are not a 'true' override because 
> of evaluation time of overrides.  We want the DEFAULTTUNE to be changeable 
> during the build process to allow multilibs, alternative configurations, etc.
> 
> So in the tunes to do override-like implementations, you will need:
> 
> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
> 
> and then in each tune fragment:
> 
> ARMPKGARCH_tune-foo = "bar"

Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top in that repo

> 
> --Mark
> 
> > Cheers,
> >
> >>
> >> Anyway, my point in this is I like having the stuff unique, but we need to be
> >> sure that you can specify more then one tune file during a build w/o clashes.
> >>
> >>>> I also still think this is a distro packaging issue and should be solved
> >>>> by the distro, even if that means more complexity there. That is the
> >>>> right place for this particular complexity IMO. I'm happy to support
> >>>> that from the core but not in something as user visible and confusing as
> >>>> this variable.
> >>>
> >>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> >>> there will be much worse then when it's defined in tune-* files, because
> >>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> >>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> >>> config) then it could be.
> >>
> >> I really don't have a strong opinion on this either way.  I know for the stuff
> >> I've done in the past (not oe-based) we've just manually configured (the
> >> equivalent of the distro conf) with the information on the handful of items that
> >> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
> >> otherwise folks don't seem to care, and re-use works fine.
> >>
> >> If the list is small (i.e. less then 10 packages) that specifying it via package
> >> specific overrides in the distro file should be fine.. if it's more then 10
> >> (typically) then we need to start looking for another approach.
> >>
> >> I'd almost suggest in the distro file you could do:
> >>
> >> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
> >> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> >>
> >> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
> >>
> >> and then everything can be encapsulated into the distro file (and distro BSPs).
> >>    The downside of this approach is that it's not the 'standard' implementation.
> >>
> >> --Mark
> >>
> >>> Cheers,
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >>>
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

[Mark Hatle]

On 10/2/12 3:38 PM, Martin Jansa wrote:
> On Tue, Oct 02, 2012 at 03:36:16PM -0500, Mark Hatle wrote:
>> On 10/2/12 1:43 PM, Martin Jansa wrote:
>>> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
>>>> Let me preface this by I have read the patch set.. Martin asked me to comment on
>>>> the items below...
>>>>
>>>> On 9/27/12 3:37 AM, Martin Jansa wrote:
>>>>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
>>>>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
>>>>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
>>>>>>> * this way xscale or arm926ejs is not used by default when some machine
>>>>>>>      includes its tune*.inc, but it's easy for DISTRO to say it wants
>>>>>>>      OPTDEFAULTTUNE for some packages or always (if they don't want to
>>>>>>>      share built packages between xscale and arm926ejs).
>>>>>>>
>>>>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>>>>>> ---
>>>>>>>     meta/conf/bitbake.conf                       | 1 +
>>>>>>>     meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
>>>>>>>     meta/conf/machine/include/tune-xscale.inc    | 3 ++-
>>>>>>>     3 files changed, 5 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>>>>>> index 9b41749..e433fcb 100644
>>>>>>> --- a/meta/conf/bitbake.conf
>>>>>>> +++ b/meta/conf/bitbake.conf
>>>>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
>>>>>>>     HOST_AS_ARCH = "${TARGET_AS_ARCH}"
>>>>>>>     HOST_EXEEXT = ""
>>>>>>>
>>>>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
>>>>>>>     TUNE_ARCH ??= "INVALID"
>>>>>>>     TUNE_CCARGS ??= ""
>>>>>>>     TUNE_LDARGS ??= ""
>>>>>>
>>>>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
>>>>>> or in meaning and we need to find a better solution. I'm therefore not
>>>>>> keen on this change.
>>>>>
>>>>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
>>>>> different PKGARCH for different TUNE_CCARGS?
>>>>
>>>> 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.
>>>>
>>>> The only concern I have with that is:
>>>>
>>>> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
>>>> "-arm926ejs", "", d)}"
>>>>
>>>> That probably should be a .= instead of just '='.  That way if the user loads
>>>> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
>>>> using the overrides would work as well for this.. i.e.
>>>> ARMPKGSFX_CPU_tune-arm926ejs instead...
>>>>
>>>> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
>>>> fine as well, and it was designed to be overriden.. but again the .= or
>>>> -tune_... syntax should be used...
>>>
>>> I've updated contrib/jansa/tune-test with this.
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
>>>
>>> While changing that to use e.g.
>>> ARMPKGARCH_tune-xscale
>>> I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
>>> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
>>> in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
>>> arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).
>>>
>>> This makes whole
>>> TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
>>> a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
>>
>> I've clarified with RP on this.  Tune values are not a 'true' override because
>> of evaluation time of overrides.  We want the DEFAULTTUNE to be changeable
>> during the build process to allow multilibs, alternative configurations, etc.
>>
>> So in the tunes to do override-like implementations, you will need:
>>
>> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
>>
>> and then in each tune fragment:
>>
>> ARMPKGARCH_tune-foo = "bar"
>
> Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top in that repo

Ya, I agree a bit ugly.. but I do think it's reasonable in this case.

--Mark

>>
>> --Mark
>>
>>> Cheers,
>>>
>>>>
>>>> Anyway, my point in this is I like having the stuff unique, but we need to be
>>>> sure that you can specify more then one tune file during a build w/o clashes.
>>>>
>>>>>> I also still think this is a distro packaging issue and should be solved
>>>>>> by the distro, even if that means more complexity there. That is the
>>>>>> right place for this particular complexity IMO. I'm happy to support
>>>>>> that from the core but not in something as user visible and confusing as
>>>>>> this variable.
>>>>>
>>>>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
>>>>> there will be much worse then when it's defined in tune-* files, because
>>>>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
>>>>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
>>>>> config) then it could be.
>>>>
>>>> I really don't have a strong opinion on this either way.  I know for the stuff
>>>> I've done in the past (not oe-based) we've just manually configured (the
>>>> equivalent of the distro conf) with the information on the handful of items that
>>>> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
>>>> otherwise folks don't seem to care, and re-use works fine.
>>>>
>>>> If the list is small (i.e. less then 10 packages) that specifying it via package
>>>> specific overrides in the distro file should be fine.. if it's more then 10
>>>> (typically) then we need to start looking for another approach.
>>>>
>>>> I'd almost suggest in the distro file you could do:
>>>>
>>>> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
>>>> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
>>>>
>>>> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
>>>>
>>>> and then everything can be encapsulated into the distro file (and distro BSPs).
>>>>     The downside of this approach is that it's not the 'standard' implementation.
>>>>
>>>> --Mark
>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openembedded-core mailing list
>>>>> Openembedded-core@lists.openembedded.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>

[RFC 3/5] optimized-tune.inc: add optional distro include

[Martin Jansa]

* selects more optimized DEFAULTTUNE for some packages
* for some machines it could be de same as DEFAULTTUNE

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/distro/include/optimized-tune.inc | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 meta/conf/distro/include/optimized-tune.inc

diff --git a/meta/conf/distro/include/optimized-tune.inc b/meta/conf/distro/include/optimized-tune.inc
new file mode 100644
index 0000000..25e1320
--- /dev/null
+++ b/meta/conf/distro/include/optimized-tune.inc
@@ -0,0 +1,2 @@
+# list of packages where it's worth it using OPTDEFAULTTUNE with cost of separate package feed
+DEFAULTTUNE_pn-openssl = "${OPTDEFAULTTUNE}"
-- 
1.7.12

[RFC 4/5] bitbake.conf: add TUNE_CCARGS[vardepvalue]

[Martin Jansa]

* we don't care about expression but value
* e.g. tune-xscale and tune-arm926ejs have different expression
  in TUNE_CCARGS but with the same DEFAULTTUNE the result is the same
  http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030032.html

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/bitbake.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e433fcb..519a7fc 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -98,6 +98,7 @@ HOST_EXEEXT = ""
 OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
 TUNE_ARCH ??= "INVALID"
 TUNE_CCARGS ??= ""
+TUNE_CCARGS[vardepvalue] = "${TUNE_CCARGS}"
 TUNE_LDARGS ??= ""
 TUNE_ASARGS ??= ""
 TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
-- 
1.7.12

[RFC 5/5] tune-xscale, tune-arm926ejs: drop ARMPKGSFX_CPU, change ARMPKGARCH instead

[Martin Jansa]

* xscale will be prefix not suffix, but also we need to show other flags
  like thumb/dsp/fpu/eabi/endian

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/machine/include/arm/README         | 5 +----
 meta/conf/machine/include/arm/arch-arm.inc   | 4 +---
 meta/conf/machine/include/tune-arm926ejs.inc | 4 ++--
 meta/conf/machine/include/tune-xscale.inc    | 6 +++---
 4 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/meta/conf/machine/include/arm/README b/meta/conf/machine/include/arm/README
index 7e52902..a1beb75 100644
--- a/meta/conf/machine/include/arm/README
+++ b/meta/conf/machine/include/arm/README
@@ -16,7 +16,7 @@ default.  The format must be of the form:
 <armversion>[t][e][hf][b][-vfp][-neon]
 
 TUNE_PKGARCH is defined as:
-${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU}
+${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
 
 ARMPKGARCH - This is the core package arch component specified by each 
 tuning.  This is the primary identifier of a tuning.  Usual values are:
@@ -38,6 +38,3 @@ the core arch-arm.inc file.
 
 ARMPKGSFX_FPU - This is the FPU specific suffix.  The suffix indicates 
 specific FPU optimizations.  'vfp' and 'neon' are both defined.
-
-ARMPKGSFX_CPU - This is the CPU specific suffix.  The suffix indicates
-that specific CPU optimizations were used.
diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
index 6f22c94..da51044 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -4,14 +4,12 @@ TUNEVALID[bigendian] = "Enable big-endian mode."
 ARMPKGARCH ??= "arm"
 ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
 ARMPKGSFX_FPU ??= ""
-ARMPKGSFX_CPU ??= ""
-ARMPKGSFX_CPU[vardepvalue] = "${ARMPKGSFX_CPU}"
 ARMPKGSFX_DSP ??= ""
 ARMPKGSFX_EABI ??= ""
 ARMPKGSFX_THUMB ??= ""
 
 TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
-TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU}"
+TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
 ABIEXTENSION = "eabi"
 
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 4406b3c..f50c22d 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -1,6 +1,6 @@
 DEFAULTTUNE ?= "armv5te"
 OPTDEFAULTTUNE ?= "arm926ejs"
-ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
+ARMPKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "arm926ejs-", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
@@ -9,4 +9,4 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm92
 
 AVAILTUNES += "arm926ejs"
 TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
-PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-arm926ejs"
+PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejs-te"
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index a04a5e1..e17f321 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,6 +1,6 @@
 DEFAULTTUNE ?= "armv5te"
 OPTDEFAULTTUNE ?= "xscale"
-ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-xscale", "", d)}"
+ARMPKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "xscale-", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
@@ -9,11 +9,11 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale",
 
 AVAILTUNES += "xscale"
 TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
-PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} xscale-te"
 
 AVAILTUNES += "xscale-be"
 TUNE_FEATURES_tune-xscale-be = "${TUNE_FEATURES_tune-armv5teb} xscale bigendian"
-PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb} armv5teb-xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb} xscale-teb"
 
 # webkit-gtk has alignment issues with double instructions on armv5 so
 # disable them here
-- 
1.7.12

[PATCH 0/7] conf/machine: fix arm tune files

[Martin Jansa]

Tested with sstate-diff.sh script and fake machine configs added in this branch:
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test

Fixes [YOCTO #3219]

The following changes since commit df2b756436b90f8f9ff229ba64d0af30d9d4f923:

  common-licenses: Adding bzip (2012-10-04 14:09:06 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib jansa/tune2
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/tune2

Martin Jansa (7):
  tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with
    xscale in TUNE_FEATURES
  bitbake.conf: add TUNE_CCARGS[vardepvalue]
  tune-cortexr4: fix march value
  arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes
  arch-arm: define different ARMPKGARCH when different CCARGS are used
  tune-*: define more generic DEFAULTTUNE to share feed between
    machines
  scripts/sstate-diff.sh: add simple script to compare sstate checksums
    between MACHINEs

 meta/conf/bitbake.conf                           |  1 +
 meta/conf/machine/include/arm/arch-arm.inc       |  2 +-
 meta/conf/machine/include/arm/arch-armv4.inc     |  6 +++--
 meta/conf/machine/include/arm/arch-armv5-dsp.inc | 12 +++++++++
 meta/conf/machine/include/arm/arch-armv5.inc     | 14 +++++++++--
 meta/conf/machine/include/arm/arch-armv6.inc     | 10 ++++++--
 meta/conf/machine/include/arm/arch-armv7a.inc    | 18 +++++++++++--
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  3 ++-
 meta/conf/machine/include/tune-arm920t.inc       |  3 ++-
 meta/conf/machine/include/tune-arm926ejs.inc     |  4 +--
 meta/conf/machine/include/tune-arm9tdmi.inc      |  3 ++-
 meta/conf/machine/include/tune-cortexa8.inc      |  8 +++++-
 meta/conf/machine/include/tune-cortexa9.inc      |  8 +++++-
 meta/conf/machine/include/tune-cortexm1.inc      |  3 ++-
 meta/conf/machine/include/tune-cortexm3.inc      |  2 +-
 meta/conf/machine/include/tune-cortexr4.inc      |  4 +--
 meta/conf/machine/include/tune-ep9312.inc        |  4 +--
 meta/conf/machine/include/tune-iwmmxt.inc        |  4 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 ++-
 meta/conf/machine/include/tune-xscale.inc        |  8 +++---
 scripts/sstate-diff.sh                           | 32 ++++++++++++++++++++++++
 21 files changed, 122 insertions(+), 30 deletions(-)
 create mode 100755 scripts/sstate-diff.sh

-- 
1.7.12

[PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES

[Martin Jansa]

* without this you'll get different sstate checksum for webkit-gtk and
  cairo even when you build them with DEFAULTTUNE == armv5te
* maybe this isn't needed at all anymore or if it is then it should be
  applied in arm-armv5.inc for all armv5te devices, not only xscale?

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/machine/include/tune-xscale.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index 80a3683..0d5d060 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -15,5 +15,5 @@ PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
 
 # webkit-gtk has alignment issues with double instructions on armv5 so
 # disable them here
-TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
-TUNE_CCARGS_pn-cairo = "-march=armv4t"
+TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"
+TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"
-- 
1.7.12

Re: [PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES

[Khem Raj]

On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>
> -TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
> -TUNE_CCARGS_pn-cairo = "-march=armv4t"
> +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"
> +TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"

I would rather try to remove this option completely if possible. I
wonder if we still need to target armv4t when building on xscale
may be the reason it was added is no more relevant ?

Re: [PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Thu, Oct 04, 2012 at 09:55:01AM -0700, Khem Raj wrote:
> On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> >
> > -TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
> > -TUNE_CCARGS_pn-cairo = "-march=armv4t"
> > +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"
> > +TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"
> 
> I would rather try to remove this option completely if possible. I
> wonder if we still need to target armv4t when building on xscale
> may be the reason it was added is no more relevant ?

I think the same (as written in commit message). Now it won't be used by
default at least (only if someone asks for DEFAULTTUNE xscale for
webkit-gtk or cairo).

Cheers,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

[PATCH 2/7] bitbake.conf: add TUNE_CCARGS[vardepvalue]

[Martin Jansa]

* we don't care about expression but value
* e.g. tune-xscale and tune-arm926ejs have different expression
  in TUNE_CCARGS but with the same DEFAULTTUNE the result is the same
  http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030032.html

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/bitbake.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5cb5b13..fa8fb5e 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -98,6 +98,7 @@ HOST_EXEEXT = ""
 
 TUNE_ARCH ??= "INVALID"
 TUNE_CCARGS ??= ""
+TUNE_CCARGS[vardepvalue] = "${TUNE_CCARGS}"
 TUNE_LDARGS ??= ""
 TUNE_ASARGS ??= ""
 TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
-- 
1.7.12

[PATCH 3/7] tune-cortexr4: fix march value

[Martin Jansa]

* probably copy&paste error from tune-cortexm3.conf
  commit 789dcb8e68a2ab9784ac10ab36815010c61af2fc
  Author: Richard Purdie <richard.purdie@linuxfoundation.org>
  Date:   Mon Jul 25 19:03:24 2011 +0100

    Add ARM tune file overhaul based largely on work from Mark Hatle

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/machine/include/tune-cortexr4.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
index d1fc607..c8c2bfb 100644
--- a/meta/conf/machine/include/tune-cortexr4.inc
+++ b/meta/conf/machine/include/tune-cortexr4.inc
@@ -7,7 +7,7 @@ TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}"
 
 TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-r", "", d)}"
 
 AVAILTUNES += "cortexr4"
 TUNE_FEATURES_tune-cortexr4 = "armv7r vfp cortexr4"
-- 
1.7.12

Re: [PATCH 3/7] tune-cortexr4: fix march value

[Khem Raj]

On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>
> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-r", "", d)}"

yeah this is ok

[PATCH 4/7] arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes

[Martin Jansa]

* tune-foo is not valid override, for it to work I had to add
  ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
  but that doesn't work without value defined for every supported
  DEFAULTTUNE value, otherwise it's expanded like this
  TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/machine/include/arm/arch-arm.inc       |  2 +-
 meta/conf/machine/include/arm/arch-armv4.inc     |  6 ++++--
 meta/conf/machine/include/arm/arch-armv5-dsp.inc | 12 ++++++++++++
 meta/conf/machine/include/arm/arch-armv5.inc     | 14 ++++++++++++--
 meta/conf/machine/include/arm/arch-armv6.inc     | 10 ++++++++--
 meta/conf/machine/include/arm/arch-armv7a.inc    | 18 ++++++++++++++++--
 6 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
index da51044..90b80c4 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -1,7 +1,7 @@
 
 TUNEVALID[bigendian] = "Enable big-endian mode."
 
-ARMPKGARCH ??= "arm"
+ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
 ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
 ARMPKGSFX_FPU ??= ""
 ARMPKGSFX_DSP ??= ""
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
index cb747ac..07e8eec 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -1,7 +1,5 @@
 DEFAULTTUNE ?= "armv4"
 
-ARMPKGARCH ?= "armv4"
-
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
 TARGET_LD_KERNEL_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "--fix-v4bx", "", d)}"
@@ -12,6 +10,8 @@ require conf/machine/include/arm/feature-arm-thumb.inc
 
 # Little Endian
 AVAILTUNES += "armv4 armv4t"
+ARMPKGARCH_tune-armv4 ?= "armv4"
+ARMPKGARCH_tune-armv4t ?= "armv4"
 TUNE_FEATURES_tune-armv4 ?= "armv4"
 TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"
 PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
@@ -19,6 +19,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
 
 # Big Endian
 AVAILTUNES += "armv4b armv4tb"
+ARMPKGARCH_tune-armv4b ?= "armv4"
+ARMPKGARCH_tune-armv4tb ?= "armv4"
 TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
 TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
 PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
index 0f64562..0ae6411 100644
--- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -5,6 +5,8 @@ require conf/machine/include/arm/arch-armv5.inc
 
 # Little Endian
 AVAILTUNES += "armv5e armv5te"
+ARMPKGARCH_tune-armv5e ?= "armv5"
+ARMPKGARCH_tune-armv5te ?= "armv5"
 TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
 TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
 PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
@@ -12,6 +14,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e ar
 
 # Little Endian + VFP/DSP
 AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
+ARMPKGARCH_tune-armv5e-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5te-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5ehf-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5tehf-vfp ?= "armv5"
 TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
 TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
 TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
@@ -23,6 +29,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vf
 
 # Big Endian
 AVAILTUNES += "armv5eb armv5teb"
+ARMPKGARCH_tune-armv5eb ?= "armv5"
+ARMPKGARCH_tune-armv5teb ?= "armv5"
 TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
 TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
 PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5b} armv5eb"
@@ -30,6 +38,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tb} armv5eb
 
 # Big Endian + VFP/DSP
 AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
+ARMPKGARCH_tune-armv5eb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5teb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5ehfb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5tehfb-vfp ?= "armv5"
 TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
 TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian"
 TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
index 98780e5..5ed56bc 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -1,7 +1,5 @@
 DEFAULTTUNE ?= "armv5"
 
-ARMPKGARCH ?= "armv5"
-
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 TUNECONFLICTS[armv5] = "armv4"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
@@ -14,6 +12,8 @@ require conf/machine/include/arm/feature-arm-vfp.inc
 
 # Little Endian
 AVAILTUNES += "armv5 armv5t"
+ARMPKGARCH_tune-armv5 ?= "armv5"
+ARMPKGARCH_tune-armv5t ?= "armv5"
 TUNE_FEATURES_tune-armv5 ?= "armv5"
 TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
 PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
@@ -21,6 +21,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv
 
 # Little Endian + VFP/DSP
 AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
+ARMPKGARCH_tune-armv5-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5t-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5hf-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5thf-vfp ?= "armv5"
 TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp"
 TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp"
 TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
@@ -33,6 +37,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vf
 
 # Big Endian
 AVAILTUNES += "armv5b armv5tb"
+ARMPKGARCH_tune-armv5b ?= "armv5"
+ARMPKGARCH_tune-armv5tb ?= "armv5"
 TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian"
 TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian"
 PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
@@ -40,6 +46,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b ar
 
 # Big Endian + VFP/DSP
 AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp"
+ARMPKGARCH_tune-armv5b-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5tb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5hfb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5thfb-vfp ?= "armv5"
 TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian"
 TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian"
 TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
index f0fee93..451a008 100644
--- a/meta/conf/machine/include/arm/arch-armv6.inc
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -1,7 +1,5 @@
 DEFAULTTUNE ?= "armv6"
 
-ARMPKGARCH ?= "armv6"
-
 TUNEVALID[armv6] = "Enable instructions for ARMv6"
 TUNECONFLICTS[armv6] = "armv4 armv5"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
@@ -11,6 +9,10 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 # Little Endian
 AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
+ARMPKGARCH_tune-armv6 ?= "armv6"
+ARMPKGARCH_tune-armv6t ?= "armv6"
+ARMPKGARCH_tune-armv6hf ?= "armv6"
+ARMPKGARCH_tune-armv6thf ?= "armv6"
 TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
 TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"
 TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
@@ -22,6 +24,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} a
 
 # Big Endian
 AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
+ARMPKGARCH_tune-armv6b ?= "armv6"
+ARMPKGARCH_tune-armv6tb ?= "armv6"
+ARMPKGARCH_tune-armv6hfb ?= "armv6"
+ARMPKGARCH_tune-armv6thfb ?= "armv6"
 TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
 TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
 TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
index 8d6ec25..d4a1d02 100644
--- a/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -1,7 +1,5 @@
 DEFAULTTUNE ?= "armv7a"
 
-ARMPKGARCH ?= "armv7a"
-
 TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"
 TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a", "", d)}"
@@ -12,6 +10,10 @@ require conf/machine/include/arm/feature-arm-neon.inc
 
 # Little Endian base configs
 AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon"
+ARMPKGARCH_tune-armv7a ?= "armv7a"
+ARMPKGARCH_tune-armv7at ?= "armv7a"
+ARMPKGARCH_tune-armv7a-neon?= "armv7a"
+ARMPKGARCH_tune-armv7at-neon ?= "armv7a"
 TUNE_FEATURES_tune-armv7a ?= "armv7a vfp"
 TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb"
 TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
@@ -23,6 +25,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} arm
 
 # VFP Tunes
 AVAILTUNES += "armv7ahf armv7athf armv7ahf-neon armv7athf-neon"
+ARMPKGARCH_tune-armv7ahf ?= "armv7a"
+ARMPKGARCH_tune-armv7athf ?= "armv7a"
+ARMPKGARCH_tune-armv7ahf-neon?= "armv7a"
+ARMPKGARCH_tune-armv7athf-neon ?= "armv7a"
 TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
 TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
 TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
@@ -34,6 +40,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf}
 
 # Big Endian
 AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon"
+ARMPKGARCH_tune-armv7ab ?= "armv7a"
+ARMPKGARCH_tune-armv7atb ?= "armv7a"
+ARMPKGARCH_tune-armv7ab-neon?= "armv7a"
+ARMPKGARCH_tune-armv7atb-neon ?= "armv7a"
 TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian"
 TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian"
 TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
@@ -45,6 +55,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} ar
 
 # Big Endian + VFP
 AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon"
+ARMPKGARCH_tune-armv7ahfb ?= "armv7a"
+ARMPKGARCH_tune-armv7athfb ?= "armv7a"
+ARMPKGARCH_tune-armv7ahfb-neon?= "armv7a"
+ARMPKGARCH_tune-armv7athfb-neon ?= "armv7a"
 TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard"
 TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard"
 TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
-- 
1.7.12

[PATCH 5/7] arch-arm: define different ARMPKGARCH when different CCARGS are used

[Martin Jansa]

* without this tune-xscale and tune-arm926ejs were both creating
  packages in armv5te feed, but each with different -mtune, with
  OEBasicHash enabled it was causing each package to rebuild with new
  -mtune after MACHINE switch, but that doesn't make sense with output
  stored in the same armv5te feed

* this makes different feed for each -mtune, but more generic one to be
  selected with DEFAULTTUNE

* tune-iwmmxt and tune-ep9312 were already using this, just move it
  bellow AVAILTUNES and use ARMPKGARCH_tune-foo syntax

* tune-cortexr4 and tune-cortexm3 are using armv7r/armv7m as ARMPKGARCH
  because there isn't another tune to use the same -march

* Fixes [YOCTO #3219]

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 1 +
 meta/conf/machine/include/tune-arm920t.inc       | 1 +
 meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc      | 1 +
 meta/conf/machine/include/tune-cortexa8.inc      | 6 ++++++
 meta/conf/machine/include/tune-cortexa9.inc      | 6 ++++++
 meta/conf/machine/include/tune-cortexm1.inc      | 1 +
 meta/conf/machine/include/tune-cortexm3.inc      | 2 +-
 meta/conf/machine/include/tune-cortexr4.inc      | 2 +-
 meta/conf/machine/include/tune-ep9312.inc        | 4 +---
 meta/conf/machine/include/tune-iwmmxt.inc        | 4 +---
 meta/conf/machine/include/tune-strongarm1100.inc | 1 +
 meta/conf/machine/include/tune-xscale.inc        | 2 ++
 13 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
index 4f4a2eb..2efcedd 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -6,5 +6,6 @@ TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
 
 AVAILTUNES += "arm1136jfs"
+ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
 TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
index b7584ab..459d978 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -6,6 +6,7 @@ TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
 
 AVAILTUNES += "arm920t"
+ARMPKGARCH_tune-arm920t = "arm920t"
 TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
 
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 7f2cc4e..0cfeb77 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -6,6 +6,6 @@ TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
 
 AVAILTUNES += "arm926ejs"
+ARMPKGARCH_tune-arm926ejs = "arm926ejs"
 TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
-
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
index 0dc5c26..100242f 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -6,6 +6,7 @@ TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
 
 AVAILTUNES += "arm9tdmi"
+ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"
 TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
 PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
 
diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
index 9d79a58..29fbe89 100644
--- a/meta/conf/machine/include/tune-cortexa8.inc
+++ b/meta/conf/machine/include/tune-cortexa8.inc
@@ -7,6 +7,9 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex
 
 # Little Endian base configs
 AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon"
+ARMPKGARCH_tune-cortexa8 = "cortexa8"
+ARMPKGARCH_tune-cortexa8t = "cortexa8t"
+ARMPKGARCH_tune-cortexa8-neon = "cortexa8-neon"
 TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} cortexa8"
 TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} cortexa8"
 TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-armv7a-neon} cortexa8"
@@ -16,6 +19,9 @@ PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon
 
 # VFP Tunes
 AVAILTUNES += "cortexa8hf cortexa8thf cortexa8hf-neon"
+ARMPKGARCH_tune-cortexa8hf = "cortexa8hf"
+ARMPKGARCH_tune-cortexa8thf = "cortexa8thf"
+ARMPKGARCH_tune-cortexa8hf-neon = "cortexa8hf-neon"
 TUNE_FEATURES_tune-cortexa8hf ?= "${TUNE_FEATURES_tune-armv7ahf} cortexa8"
 TUNE_FEATURES_tune-cortexa8thf ?= "${TUNE_FEATURES_tune-armv7athf} cortexa8"
 TUNE_FEATURES_tune-cortexa8hf-neon ?= "${TUNE_FEATURES_tune-armv7ahf-neon} cortexa8"
diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc
index a8e27ca..e2f78d3 100644
--- a/meta/conf/machine/include/tune-cortexa9.inc
+++ b/meta/conf/machine/include/tune-cortexa9.inc
@@ -7,6 +7,9 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", "-mtune=cortex
 
 # Little Endian base configs
 AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon"
+ARMPKGARCH_tune-cortexa9 = "cortexa9"
+ARMPKGARCH_tune-cortexa9t = "cortexa9t"
+ARMPKGARCH_tune-cortexa9-neon = "cortexa9-neon"
 TUNE_FEATURES_tune-cortexa9 = "${TUNE_FEATURES_tune-armv7a} cortexa9"
 TUNE_FEATURES_tune-cortexa9t = "${TUNE_FEATURES_tune-armv7at} cortexa9"
 TUNE_FEATURES_tune-cortexa9-neon = "${TUNE_FEATURES_tune-armv7a-neon} cortexa9"
@@ -16,6 +19,9 @@ PACKAGE_EXTRA_ARCHS_tune-cortexa9-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon
 
 # VFP Tunes
 AVAILTUNES += "cortexa9hf cortexa9thf cortexa9hf-neon"
+ARMPKGARCH_tune-cortexa9hf = "cortexa9hf"
+ARMPKGARCH_tune-cortexa9thf = "cortexa9thf"
+ARMPKGARCH_tune-cortexa9hf-neon = "cortexa9hf-neon"
 TUNE_FEATURES_tune-cortexa9hf ?= "${TUNE_FEATURES_tune-armv7ahf} cortexa9"
 TUNE_FEATURES_tune-cortexa9thf ?= "${TUNE_FEATURES_tune-armv7athf} cortexa9"
 TUNE_FEATURES_tune-cortexa9hf-neon ?= "${TUNE_FEATURES_tune-armv7ahf-neon} cortexa9"
diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
index 3eecd5b..ba3cbe9 100644
--- a/meta/conf/machine/include/tune-cortexm1.inc
+++ b/meta/conf/machine/include/tune-cortexm1.inc
@@ -6,6 +6,7 @@ TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
 
 AVAILTUNES += "cortexm1"
+ARMPKGARCH_tune-cortexm1 = "cortexm1"
 TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} cortexm1"
 PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
 
diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
index 20a3c65..72acdb5 100644
--- a/meta/conf/machine/include/tune-cortexm3.inc
+++ b/meta/conf/machine/include/tune-cortexm3.inc
@@ -1,5 +1,4 @@
 DEFAULTTUNE ?= "cortexm3"
-ARMPKGARCH ?= "armv7m"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
@@ -10,6 +9,7 @@ TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}"
 
 AVAILTUNES += "cortexm3"
+ARMPKGARCH_tune-cortexm3 = "armv7m"
 TUNE_FEATURES_tune-cortexm3 = "armv7m vfp cortexm3"
 PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m-vfp"
 
diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
index c8c2bfb..3f38b6c 100644
--- a/meta/conf/machine/include/tune-cortexr4.inc
+++ b/meta/conf/machine/include/tune-cortexr4.inc
@@ -1,5 +1,4 @@
 DEFAULTTUNE ?= "cortexr4"
-ARMPKGARCH ?= "armv7r"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
@@ -10,5 +9,6 @@ TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-r", "", d)}"
 
 AVAILTUNES += "cortexr4"
+ARMPKGARCH_tune-cortexr4 = "armv7r"
 TUNE_FEATURES_tune-cortexr4 = "armv7r vfp cortexr4"
 PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r-vfp"
diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc
index f10123f..09db6b4 100644
--- a/meta/conf/machine/include/tune-ep9312.inc
+++ b/meta/conf/machine/include/tune-ep9312.inc
@@ -1,5 +1,4 @@
 DEFAULTTUNE ?= "ep9312"
-ARMPKGARCH ?= "ep9312"
 
 require conf/machine/include/arm/arch-armv4.inc
 
@@ -7,7 +6,6 @@ TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}"
 
 AVAILTUNES += "ep9312"
+ARMPKGARCH_tune-ep9312 = "ep9312"
 TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
 PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
-
-
diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
index 14f5955..113d89f 100644
--- a/meta/conf/machine/include/tune-iwmmxt.inc
+++ b/meta/conf/machine/include/tune-iwmmxt.inc
@@ -2,7 +2,6 @@
 # Please use tune-xscale for PXA255/PXA26x based processors.
 
 DEFAULTTUNE ?= "iwmmxt"
-ARMPKGARCH ?= "iwmmxt"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
@@ -10,7 +9,6 @@ TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}"
 
 AVAILTUNES += "iwmmxt"
+ARMPKGARCH_tune-iwmmxt = "iwmmxt"
 TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt"
 PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt"
-
-
diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
index 66bab8e..3beaaed 100644
--- a/meta/conf/machine/include/tune-strongarm1100.inc
+++ b/meta/conf/machine/include/tune-strongarm1100.inc
@@ -6,6 +6,7 @@ TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}"
 
 AVAILTUNES += "strongarm"
+ARMPKGARCH_tune-strongarm = "strongarm"
 TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm"
 PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
 
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index 0d5d060..d9925eb 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -6,10 +6,12 @@ TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimization
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
 
 AVAILTUNES += "xscale"
+ARMPKGARCH_tune-xscale = "xscale"
 TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
 PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
 
 AVAILTUNES += "xscale-be"
+ARMPKGARCH_tune-xscale-be = "xscale-be"
 TUNE_FEATURES_tune-xscale-be = "${TUNE_FEATURES_tune-armv5teb} xscale bigendian"
 PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
 
-- 
1.7.12

[PATCH 6/7] tune-*: define more generic DEFAULTTUNE to share feed between machines

[Martin Jansa]

* this is mostly for backwards compatibility and to share binary feed
  like it was before, but now without missing different -mtune in it
* if you want to build some package with -mtune add something like this
  to your distro config
  DEFAULTTUNE_qemuarm_pn-openssl = "arm926ejs"
  DEFAULTTUNE_qemuarmx_pn-openssl = "xscale"
  be aware that if you do this you should do it also for all packages
  which depends on openssl because if you dont and you build e.g. dhcp,
  then dhcp build for arm926ejs (even with DEFAULTTUNE armv5te) will
  depend on openssl with arm926ejs, so dhcp in armv5te feed will be
  rebuild after each MACHINE switch.
* cortexm3, cortexr4, iwmmx and ep9312 are using own DEFAULTTUNE because
  they define also different -march
* shared feeds are
  armv4t: arm920t, arm9tdmi
  armv5te: arm926ejs, xscale
  armv7a-neon: cortexa8, cortexa9

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc       | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc      | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc      | 2 +-
 meta/conf/machine/include/tune-cortexm1.inc      | 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-xscale.inc        | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
index 2efcedd..adece48 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "arm1136jfs"
+DEFAULTTUNE ?= "armv6"
 
 require conf/machine/include/arm/arch-armv6.inc
 
diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
index 459d978..3240fa8 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "arm920t"
+DEFAULTTUNE ?= "armv4t"
 
 require conf/machine/include/arm/arch-armv4.inc
 
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 0cfeb77..301a3c2 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "arm926ejs"
+DEFAULTTUNE ?= "armv5te"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
index 100242f..a981a65 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "arm9tdmi"
+DEFAULTTUNE ?= "armv4t"
 
 require conf/machine/include/arm/arch-armv4.inc
 
diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
index 29fbe89..89878d4 100644
--- a/meta/conf/machine/include/tune-cortexa8.inc
+++ b/meta/conf/machine/include/tune-cortexa8.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "cortexa8-neon"
+DEFAULTTUNE ?= "armv7a-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc
index e2f78d3..addfdad 100644
--- a/meta/conf/machine/include/tune-cortexa9.inc
+++ b/meta/conf/machine/include/tune-cortexa9.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "cortexa9-neon"
+DEFAULTTUNE ?= "armv7a-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
index ba3cbe9..c4c658b 100644
--- a/meta/conf/machine/include/tune-cortexm1.inc
+++ b/meta/conf/machine/include/tune-cortexm1.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "cortexm1"
+DEFAULTTUNE ?= "armv7a"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
index 3beaaed..fba0a1b 100644
--- a/meta/conf/machine/include/tune-strongarm1100.inc
+++ b/meta/conf/machine/include/tune-strongarm1100.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "strongarm"
+DEFAULTTUNE ?= "armv4"
 
 require conf/machine/include/arm/arch-armv4.inc
 
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index d9925eb..a48c2d9 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "xscale"
+DEFAULTTUNE ?= "armv5te"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
-- 
1.7.12

[PATCH 7/7] scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs

[Martin Jansa]

* it's not very universal, but works with default oe-core setup and
  shows basic HOW-TO, because many people still don't know how to detect
  machine specific sstate checksums
* someone can improve this with bitbake -e calls to detect BASE and to
  specify MACHINEs and TARGETs in parameter instead of hardcoded values
  in script..

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 scripts/sstate-diff.sh | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100755 scripts/sstate-diff.sh

diff --git a/scripts/sstate-diff.sh b/scripts/sstate-diff.sh
new file mode 100755
index 0000000..2d256e8
--- /dev/null
+++ b/scripts/sstate-diff.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+# Used to compare sstate checksums between MACHINES
+# Update MACHINES, TARGETS and BASE
+# Execute script and compare generated list.M files
+
+# $ diff stamps.1349348392/fake-cortexa8/list.M stamps.1349348392/fake-cortexa9/list.M | wc -l
+# 538
+
+# Then to compare sigdata use something like:
+# $ ls stamps.1349348392/*/armv7a-vfp-neon*/linux-libc*do_configure*
+#   stamps.1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025
+#   stamps.1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b
+# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc*do_configure*
+#   basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a
+#   Variable TUNE_CCARGS value changed from  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9
+
+MACHINES="fake-arm1136jf-s fake-arm920t fake-arm926ejs fake-arm9tdmi fake-cortexa8 fake-cortexa9 fake-cortexm1 fake-cortexm3 fake-cortexr4 fake-ep9312 fake-iwmmxt fake-strongarm1100 fake-xscale"
+TARGETS="dhcp"
+
+BASE="/OE/oe-core"
+OUTPUT=${BASE}/stamps.`date "+%s"`
+
+for M in ${MACHINES}; do
+  find ${BASE}/tmp-eglibc/stamps/ -name \*sigdata\* | xargs rm -f
+  mkdir -p ${OUTPUT}/${M}
+  export MACHINE=${M}; bitbake -S ${TARGETS} | tee -a ${OUTPUT}/${M}/log;
+  cp -ra ${BASE}/tmp-eglibc/stamps/* ${OUTPUT}/${M}
+  find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list
+  sed "s/om_gta0/om-gta0/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M
+  find ${BASE}/tmp-eglibc/stamps/ -name \*sigdata\* | xargs rm -f
+done
-- 
1.7.12

[PATCHv2] scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs

[Martin Jansa]

* takes tmpdir, machines and targets from command arguments or env variables

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 scripts/sstate-diff.sh | 107 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)
 create mode 100755 scripts/sstate-diff.sh

diff --git a/scripts/sstate-diff.sh b/scripts/sstate-diff.sh
new file mode 100755
index 0000000..f2c151a
--- /dev/null
+++ b/scripts/sstate-diff.sh
@@ -0,0 +1,107 @@
+#!/bin/sh
+
+# Used to compare sstate checksums between MACHINES
+# Execute script and compare generated list.M files
+
+# It's also usefull to keep older sstate checksums
+# to be able to find out why something is rebuilding 
+# after updating metadata
+
+# $ diff \
+#     sstate-diff/1349348392/fake-cortexa8/list.M \
+#     sstate-diff/1349348392/fake-cortexa9/list.M \
+#     | wc -l
+# 538
+
+# Then to compare sigdata use something like:
+# $ ls sstate-diff/1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata*
+#   sstate-diff/1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025
+#   sstate-diff/1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b
+# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata*
+#   basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a
+#   Variable TUNE_CCARGS value changed from  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9
+
+# Global vars
+tmpdir=
+machines=
+targets=
+default_machines="qemuarm qemux86 qemux86-64"
+default_targets="core-image-base"
+
+usage () {
+  cat << EOF
+Welcome to utility to compare sstate checksums between different MACHINEs.
+$0 <OPTION>
+
+Options:
+  -h, --help
+        Display this help and exit.
+
+  --tmpdir=<tmpdir>
+        Specify tmpdir, will use the environment variable TMPDIR if it is not specified.
+        Something like /OE/oe-core/tmp-eglibc (no / at the end).
+  
+  --machines=<machines>
+        List of MACHINEs separated by space, will use the environment variable MACHINES if it is not specified.
+        Default value is "qemuarm qemux86 qemux86-64".
+  
+  --targets=<targets>
+        List of targets separated by space, will use the environment variable TARGETS if it is not specified.
+        Default value is "core-image-base".
+EOF
+}
+
+# Print error information and exit.
+echo_error () {
+  echo "ERROR: $1" >&2
+  exit 1
+}
+
+while [ -n "$1" ]; do
+  case $1 in
+    --tmpdir=*)
+      tmpdir=`echo $1 | sed -e 's#^--tmpdir=##' | xargs readlink -e`
+      [ -d "$tmpdir" ] || echo_error "Invalid argument to --tmpdir"
+      shift
+        ;;
+    --machines=*)
+      machines=`echo $1 | sed -e 's#^--machines="*\([^"]*\)"*#\1#'`
+      shift
+        ;;
+    --targets=*)
+      targets=`echo $1 | sed -e 's#^--targets="*\([^"]*\)"*#\1#'`
+      shift
+        ;;
+    --help|-h)
+      usage
+      exit 0
+        ;;
+    *)
+      echo "Invalid arguments $*"
+      echo_error "Try '$0 -h' for more information."
+        ;;
+  esac
+done
+
+# tmpdir directory, use environment variable TMPDIR
+# if it was not specified, otherwise, error.
+[ -n "$tmpdir" ] || tmpdir=$TMPDIR
+[ -n "$tmpdir" ] || echo_error "No tmpdir found!"
+[ -d "$tmpdir" ] || echo_error "Invalid tmpdir \"$tmpdir\""
+[ -n "$machines" ] || machines=$MACHINES
+[ -n "$machines" ] || machines=$default_machines
+[ -n "$targets" ] || targets=$TARGETS
+[ -n "$targets" ] || targets=$default_targets
+
+OUTPUT=${tmpdir}/sstate-diff/`date "+%s"`
+
+for M in ${machines}; do
+  find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f
+  mkdir -p ${OUTPUT}/${M}
+  export MACHINE=${M}; bitbake -S ${targets} | tee -a ${OUTPUT}/${M}/log;
+  cp -ra ${tmpdir}/stamps/* ${OUTPUT}/${M}
+  find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list
+  M_UNDERSCORE=`echo ${M} | sed 's/-/_/g'`
+  sed "s/${M_UNDERSCORE}/MACHINE/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M
+  find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f
+done
-- 
1.8.0

Re: [PATCHv2] scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs

[Richard Purdie]

On Tue, 2012-12-04 at 13:07 +0100, Martin Jansa wrote:
> * takes tmpdir, machines and targets from command arguments or env variables
> 
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
>  scripts/sstate-diff.sh | 107 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 107 insertions(+)
>  create mode 100755 scripts/sstate-diff.sh
> 
> diff --git a/scripts/sstate-diff.sh b/scripts/sstate-diff.sh

Can we call this something a little more intuitive like
sstate-diff-machines ?

Cheers,

Richard

[PATCHv3] scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs

[Martin Jansa]

* takes tmpdir, machines and targets from command arguments or env variables

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 scripts/sstate-diff-machines.sh | 107 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)
 create mode 100755 scripts/sstate-diff-machines.sh

diff --git a/scripts/sstate-diff-machines.sh b/scripts/sstate-diff-machines.sh
new file mode 100755
index 0000000..f2c151a
--- /dev/null
+++ b/scripts/sstate-diff-machines.sh
@@ -0,0 +1,107 @@
+#!/bin/sh
+
+# Used to compare sstate checksums between MACHINES
+# Execute script and compare generated list.M files
+
+# It's also usefull to keep older sstate checksums
+# to be able to find out why something is rebuilding 
+# after updating metadata
+
+# $ diff \
+#     sstate-diff/1349348392/fake-cortexa8/list.M \
+#     sstate-diff/1349348392/fake-cortexa9/list.M \
+#     | wc -l
+# 538
+
+# Then to compare sigdata use something like:
+# $ ls sstate-diff/1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata*
+#   sstate-diff/1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025
+#   sstate-diff/1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b
+# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata*
+#   basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a
+#   Variable TUNE_CCARGS value changed from  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9
+
+# Global vars
+tmpdir=
+machines=
+targets=
+default_machines="qemuarm qemux86 qemux86-64"
+default_targets="core-image-base"
+
+usage () {
+  cat << EOF
+Welcome to utility to compare sstate checksums between different MACHINEs.
+$0 <OPTION>
+
+Options:
+  -h, --help
+        Display this help and exit.
+
+  --tmpdir=<tmpdir>
+        Specify tmpdir, will use the environment variable TMPDIR if it is not specified.
+        Something like /OE/oe-core/tmp-eglibc (no / at the end).
+  
+  --machines=<machines>
+        List of MACHINEs separated by space, will use the environment variable MACHINES if it is not specified.
+        Default value is "qemuarm qemux86 qemux86-64".
+  
+  --targets=<targets>
+        List of targets separated by space, will use the environment variable TARGETS if it is not specified.
+        Default value is "core-image-base".
+EOF
+}
+
+# Print error information and exit.
+echo_error () {
+  echo "ERROR: $1" >&2
+  exit 1
+}
+
+while [ -n "$1" ]; do
+  case $1 in
+    --tmpdir=*)
+      tmpdir=`echo $1 | sed -e 's#^--tmpdir=##' | xargs readlink -e`
+      [ -d "$tmpdir" ] || echo_error "Invalid argument to --tmpdir"
+      shift
+        ;;
+    --machines=*)
+      machines=`echo $1 | sed -e 's#^--machines="*\([^"]*\)"*#\1#'`
+      shift
+        ;;
+    --targets=*)
+      targets=`echo $1 | sed -e 's#^--targets="*\([^"]*\)"*#\1#'`
+      shift
+        ;;
+    --help|-h)
+      usage
+      exit 0
+        ;;
+    *)
+      echo "Invalid arguments $*"
+      echo_error "Try '$0 -h' for more information."
+        ;;
+  esac
+done
+
+# tmpdir directory, use environment variable TMPDIR
+# if it was not specified, otherwise, error.
+[ -n "$tmpdir" ] || tmpdir=$TMPDIR
+[ -n "$tmpdir" ] || echo_error "No tmpdir found!"
+[ -d "$tmpdir" ] || echo_error "Invalid tmpdir \"$tmpdir\""
+[ -n "$machines" ] || machines=$MACHINES
+[ -n "$machines" ] || machines=$default_machines
+[ -n "$targets" ] || targets=$TARGETS
+[ -n "$targets" ] || targets=$default_targets
+
+OUTPUT=${tmpdir}/sstate-diff/`date "+%s"`
+
+for M in ${machines}; do
+  find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f
+  mkdir -p ${OUTPUT}/${M}
+  export MACHINE=${M}; bitbake -S ${targets} | tee -a ${OUTPUT}/${M}/log;
+  cp -ra ${tmpdir}/stamps/* ${OUTPUT}/${M}
+  find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list
+  M_UNDERSCORE=`echo ${M} | sed 's/-/_/g'`
+  sed "s/${M_UNDERSCORE}/MACHINE/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M
+  find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f
+done
-- 
1.8.0

[PATCHv4] scripts/sstate-diff-machines.sh: add simple script to compare sstate checksums between MACHINEs

[Martin Jansa]

* takes tmpdir, machines and targets from command arguments or env variables

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 scripts/sstate-diff-machines.sh | 107 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)
 create mode 100755 scripts/sstate-diff-machines.sh

diff --git a/scripts/sstate-diff-machines.sh b/scripts/sstate-diff-machines.sh
new file mode 100755
index 0000000..f2c151a
--- /dev/null
+++ b/scripts/sstate-diff-machines.sh
@@ -0,0 +1,107 @@
+#!/bin/sh
+
+# Used to compare sstate checksums between MACHINES
+# Execute script and compare generated list.M files
+
+# It's also usefull to keep older sstate checksums
+# to be able to find out why something is rebuilding 
+# after updating metadata
+
+# $ diff \
+#     sstate-diff/1349348392/fake-cortexa8/list.M \
+#     sstate-diff/1349348392/fake-cortexa9/list.M \
+#     | wc -l
+# 538
+
+# Then to compare sigdata use something like:
+# $ ls sstate-diff/1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata*
+#   sstate-diff/1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025
+#   sstate-diff/1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b
+# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata*
+#   basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a
+#   Variable TUNE_CCARGS value changed from  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to  -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9
+
+# Global vars
+tmpdir=
+machines=
+targets=
+default_machines="qemuarm qemux86 qemux86-64"
+default_targets="core-image-base"
+
+usage () {
+  cat << EOF
+Welcome to utility to compare sstate checksums between different MACHINEs.
+$0 <OPTION>
+
+Options:
+  -h, --help
+        Display this help and exit.
+
+  --tmpdir=<tmpdir>
+        Specify tmpdir, will use the environment variable TMPDIR if it is not specified.
+        Something like /OE/oe-core/tmp-eglibc (no / at the end).
+  
+  --machines=<machines>
+        List of MACHINEs separated by space, will use the environment variable MACHINES if it is not specified.
+        Default value is "qemuarm qemux86 qemux86-64".
+  
+  --targets=<targets>
+        List of targets separated by space, will use the environment variable TARGETS if it is not specified.
+        Default value is "core-image-base".
+EOF
+}
+
+# Print error information and exit.
+echo_error () {
+  echo "ERROR: $1" >&2
+  exit 1
+}
+
+while [ -n "$1" ]; do
+  case $1 in
+    --tmpdir=*)
+      tmpdir=`echo $1 | sed -e 's#^--tmpdir=##' | xargs readlink -e`
+      [ -d "$tmpdir" ] || echo_error "Invalid argument to --tmpdir"
+      shift
+        ;;
+    --machines=*)
+      machines=`echo $1 | sed -e 's#^--machines="*\([^"]*\)"*#\1#'`
+      shift
+        ;;
+    --targets=*)
+      targets=`echo $1 | sed -e 's#^--targets="*\([^"]*\)"*#\1#'`
+      shift
+        ;;
+    --help|-h)
+      usage
+      exit 0
+        ;;
+    *)
+      echo "Invalid arguments $*"
+      echo_error "Try '$0 -h' for more information."
+        ;;
+  esac
+done
+
+# tmpdir directory, use environment variable TMPDIR
+# if it was not specified, otherwise, error.
+[ -n "$tmpdir" ] || tmpdir=$TMPDIR
+[ -n "$tmpdir" ] || echo_error "No tmpdir found!"
+[ -d "$tmpdir" ] || echo_error "Invalid tmpdir \"$tmpdir\""
+[ -n "$machines" ] || machines=$MACHINES
+[ -n "$machines" ] || machines=$default_machines
+[ -n "$targets" ] || targets=$TARGETS
+[ -n "$targets" ] || targets=$default_targets
+
+OUTPUT=${tmpdir}/sstate-diff/`date "+%s"`
+
+for M in ${machines}; do
+  find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f
+  mkdir -p ${OUTPUT}/${M}
+  export MACHINE=${M}; bitbake -S ${targets} | tee -a ${OUTPUT}/${M}/log;
+  cp -ra ${tmpdir}/stamps/* ${OUTPUT}/${M}
+  find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list
+  M_UNDERSCORE=`echo ${M} | sed 's/-/_/g'`
+  sed "s/${M_UNDERSCORE}/MACHINE/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M
+  find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f
+done
-- 
1.8.0