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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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