Re: [OE-core] [PATCH] perl-version: make PERL* assignments non-immediate

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

On Tue, 2023-04-04 at 19:38 -0500, Patrick Williams wrote:
> The perl-version.bbclass executes functions which can depend on
> variables potentially populated by native, such as `libdir`.  The
> sanity `native-last` suggests that recipes should `inherit native`
> last, but when that is done the variables like PERLVERSION end up
> as `None`, since `${STAGING_LIBDIR}` needs `${libdir}` which is not
> yet populated (by native).
> 
> Switch these variables to be non-immediate, which then allows the
> `${libdir}` to be properly populated.
> 
> It appears that meta-openembedded/meta-perl does not use either
> PERLVERSION or PERLARCH, nor is it used anywhere in `poky`.
> meta-security/meta-perl uses PERLVERSION in one recipe's `do_install`
> step.  OpenBMC's meta-phosphor similarly uses PERLVERSION in a
> `do_install` step.  Therefore, it should be safe to make this
> non-immediate.
> 
> Fixes: openbmc/openbmc#3770
> Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
> ---
>  meta/classes-recipe/perl-version.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes-recipe/perl-version.bbclass b/meta/classes-recipe/perl-version.bbclass
> index 269ac9eb31..e4913dd502 100644
> --- a/meta/classes-recipe/perl-version.bbclass
> +++ b/meta/classes-recipe/perl-version.bbclass
> @@ -26,7 +26,7 @@ def get_perl_version(d):
>              return m.group(1)
>      return None
>  
> -PERLVERSION := "${@get_perl_version(d)}"
> +PERLVERSION = "${@get_perl_version(d)}"
>  PERLVERSION[vardepvalue] = ""
>  
>  
> @@ -49,7 +49,7 @@ def get_perl_arch(d):
>              return m.group(1)
>      return None
>  
> -PERLARCH := "${@get_perl_arch(d)}"
> +PERLARCH = "${@get_perl_arch(d)}"
>  PERLARCH[vardepvalue] = ""
>  
>  # Determine the staged arch of perl-native from the perl configuration file

Most code seems to use ${@get_perl_version(d)} and ${@get_perl_arch(d)}
directly so perhaps we should just remove the above instead and use
these in meta-security too?

Cheers,

Richard