[OE-core] [PATCH 4/4] native.bbclass: poison TARGET_CFLAGS etc for native builds

[Richard Purdie]

On Fri, 2016-02-26 at 21:53 -0800, Andre McCurdy wrote:
> TARGET_* FLAGS are never passed to the native toolchain. However,
> they are exported so their values affect the checksum of every task.
> 
> Replace with fixed values to both avoid any unnecessary rebuilding
> of native packages when target flags are changed (as before) and now
> also to poison any accidental use of target flags with the native
> toolchain.
> 
> Signed-off-by: Andre McCurdy <armccurdy at gmail.com>
> ---
>  meta/classes/native.bbclass | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/classes/native.bbclass
> b/meta/classes/native.bbclass
> index f67ef00..34c08b2 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -26,10 +26,18 @@ TARGET_PREFIX = "${BUILD_PREFIX}"
>  TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
>  TARGET_LD_ARCH = "${BUILD_LD_ARCH}"
>  TARGET_AS_ARCH = "${BUILD_AS_ARCH}"
> -TARGET_CPPFLAGS = "${BUILD_CPPFLAGS}"
> -TARGET_CFLAGS = "${BUILD_CFLAGS}"
> -TARGET_CXXFLAGS = "${BUILD_CXXFLAGS}"
> -TARGET_LDFLAGS = "${BUILD_LDFLAGS}"
> +
> +# TARGET_* FLAGS are never passed to the native toolchain. However,
> they are
> +# exported so their values affect the checksum of every task.
> Replace with fixed
> +# values to both avoid any unnecessary rebuilding of native packages
> when target
> +# flags are changed and to poison any accidental use of target flags
> with the
> +# native toolchain.
> +TARGET_CPPFLAGS = "--target-cppflag-never-passed-to-the-native
> -toolchain"
> +TARGET_CFLAGS = "--target-cflag-never-passed-to-the-native
> -toolchain"
> +TARGET_CXXFLAGS = "--target-cxxflag-never-passed-to-the-native
> -toolchain"
> +TARGET_LDFLAGS = "--target-ldflag-never-passed-to-the-native
> -toolchain"

Wouldn't it perhaps be nicer just to unexport these?

I think

TARGET_CPPFLAGS[unexport] = "1"

might do it or we could do:

delvarFlag("TARGET_CPPFLAGS", "export")

?

Regardless of approach, this is likely going to need some extensive
testing.

Cheers,

Richard