On Mon, 2011-08-01 at 00:36 -0700, Saul Wold wrote:
> From: Mark Hatle <mark.ha...@windriver.com>
>
> We need to add the tune-* override in order for more complicated tune
> features to function properly.
>
> Signed-off-by: Mark Hatle <mark.ha...@windriver.com>
> ---
> meta/conf/bitbake.conf | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 9c80f11..11dfb6d 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -637,9 +637,10 @@ AUTO_LIBNAME_PKGS = "${PACKAGES}"
> #
> # This works for functions as well, they are really just environment
> variables.
> # Default OVERRIDES to make compilation fail fast in case of build system
> misconfiguration.
> -OVERRIDES =
> "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
> +OVERRIDES =
> "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${TUNEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
> DISTROOVERRIDES ?= "${DISTRO}"
> MACHINEOVERRIDES ?= "${MACHINE}"
> +TUNEOVERRIDES ?= "tune-${DEFAULTTUNE}"
>
> CPU_FEATURES ?= ""
> CPU_FEATURES_arm ?= "vfp"
This is a really bad idea and evidently hasn't been tested or thought
through :(
Why? The problem is you can't "unset" an override. This means you will
lock DEFAULTTUNE's values into the system and if you then want to change
to a different multilib the result will be confused at best.
So I'm afraid this is going to need a rethink.
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
