On Tue, 2012-10-30 at 17:33 +0800, Robert Yang wrote:
> Add the new override way CLASSOVERRIDE = "class-multilib" to
> multilib.bbclass, and add the check code to sanity.bbclass, we keep both
> the old and new way, which means, both of the following are supported:
> 
> virtclass-multilib
> class-multilib
> 
> [YOCTO #3297]
> 
> Signed-off-by: Robert Yang <[email protected]>
> ---
>  meta/classes/multilib.bbclass | 2 ++
>  meta/classes/sanity.bbclass   | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index 77ccce4..2dd2f85 100644
> --- a/meta/classes/multilib.bbclass
> +++ b/meta/classes/multilib.bbclass
> @@ -1,3 +1,5 @@
> +CLASSOVERRIDE = "class-multilib"
> +
>  python multilib_virtclass_handler () {
>      if not isinstance(e, bb.event.RecipePreFinalise):
>          return
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 3806bc5..ba1cd6d 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -122,7 +122,8 @@ def check_toolchain(data):
>                  tune_error_set.append("The multilib '%s' appears more than 
> once." % lib)
>              else:
>                  seen_libs.append(lib)
> -            tune = data.getVar("DEFAULTTUNE_virtclass-multilib-%s" % lib, 
> True)
> +            tune = data.getVar("DEFAULTTUNE_virtclass-multilib-%s" % lib, 
> True) or \
> +                   data.getVar("DEFAULTTUNE_class-multilib-%s" % lib, True)
>              if tune in seen_tunes:
>                  tune_error_set.append("The tuning '%s' appears in more than 
> one multilib." % tune)
>              else:

Sorry but this isn't right. The multilib case is special since it sets
"class-multilib-xxx", not "class-multilib" without the suffix. The above
changes are just going to confuse people and depending on what you do in
other patches, may or may not work.

Can you resend the patch set just changing the native/nativesdk values
please? We can then look at multilib specifically as a follow up.

Cheers,

Richard


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to