[OE-core] [PATCH v4 2/4] ptest.bbclass: Add feature to populate a binary directory

[Richard Purdie]

On Tue, 2019-04-09 at 00:44 -0500, Mariano Lopez wrote:
> This adds the functionality to create a binary directory within
> PTEST_PATH directory. This directory will be populated with
> symlinks pointing to the binaries installed by the package and
> then renamed by update-alternatives. This way the ptest only needs
> to source this binary directory in order to use the expected
> binaries.
> 
> To enable this feature just add PTEST_BINDIR = "1" to the recipe.
> 
> [YOCTO #12597]
> [YOCTO #13238]
> 
> Signed-off-by: Mariano Lopez <just.another.mariano at gmail.com>
> ---
>  meta/classes/ptest.bbclass | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
> index 97865c9338..e87a9659cb 100644
> --- a/meta/classes/ptest.bbclass
> +++ b/meta/classes/ptest.bbclass
> @@ -65,6 +65,38 @@ do_install_ptest_base() {
>      done
>  }
>  
> +PTEST_BINDIR_PKGD_PATH = "${PKGD}${PTEST_PATH}/bin"
> +
> +# This function needs to run after apply_update_alternative_renames
> because the
> +# aforementioned function will update the ALTERNATIVE_LINK_NAME
> flag. Append is
> +# used here to make this function to run as late as possible.
> +PACKAGE_PREPROCESS_FUNCS_append = "${@bb.utils.contains('PTEST_BINDI
> R', '1', \
> +                                    bb.utils.contains('PTEST_ENABLED
> ', '1', ' ptest_update_alternatives', '', d), '', d)}"
> +
> +python ptest_update_alternatives() {
> +    """
> +    This function will generate the symlinks in the
> PTEST_BINDIR_PKGD_PATH
> +    to match the renamed binaries by update-alternatives.
> +    """
> +
> +    if not bb.data.inherits_class('update-alternatives', d) \
> +           or not update_alternatives_enabled(d):
> +        return
> +
> +    bb.note("Generating symlinks for ptest")
> +    bin_paths = { os.environ["bindir"], os.environ["base_bindir"],

I'm going to merge this but is there a good reason you're using
os.environ[] here? If not we should merge a small fixup to use
d.getVar() since ultimately we don't really want these things in the
environment if we can help it.

Cheers,

Richard