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

[Martin Jansa <martin.jansa@gmail.com>]

[-- 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 --]