Hi guys,
Thanks for your work on this...
> On Mar 13, 2019, at 14:26, Manjukumar Matha
> wrote:
>
> From: Alejandro Enedino Hernandez Samaniego
>
> libmali provides GL backends based on x11, fbdev and wayland,
> we should be able to switch between them at runtime since it is
> the same ABI, it should only be a matter of loading the correct
> shared library by the interpreter (dynamic linker).
>
> Use the update-alternatives class, to provide a way for the user
> to choose the desired backend at runtime, do this by setting
> priorities, the package with the highest priority will be chosen
> as default at build time, but it can easily be changed at runtime
> afterwards.
> This change implies that the libmali package will install all
Nitpicking: missing line between above paragraph separation.
> backends regardless of which one was chosen, but it will only use
> one as default.
>
> Use the x11 backend by default at build time; given that it is
> the same ABI, applications which depend on libmali, can build
> regardless of the chosen backend at build time.
Mh. Since it doesn't make a difference at build time, perhaps using the
"headless" backend would be the better, lowest dependency, choice.
>
> Update-alternatives uses a set of commands on the postinst
> scripts when creating the root filesystem, which basically create
> the soft link between the chosen alternative and the binary/library.
> This usually works seamlessly (for binaries), but it does not in the
> case of libraries, because ldconfig is run at the end of the
> do_rootfs task, and it removes the link that was just created,
> it is important to note that this is simply normal ldconfig behavior
> and its not something we can fix, so we defer execution of
> update-alternatives until the first boot, hence avoiding the link
> removal by ldconfig.
>
> Switching backends at build time will also help to avoid longer
> build times, since it will only invalidate the do_package task,
> rebuilding an image after switching a backend (at build time)
> should only execute the do_package task along with the do_rootfs
> task.
Hooray!
>
> Signed-off-by: Alejandro Enedino Hernandez Samaniego
> Signed-off-by: Manjukumar Matha
> ---
> .../recipes-graphics/libgles/libmali-xlnx.bb | 101 ++---
> 1 file changed, 67 insertions(+), 34 deletions(-)
>
> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> index 504ea6d..7191c25 100644
> --- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> @@ -4,9 +4,9 @@ LICENSE = "Proprietary"
> LICENSE_FLAGS = "xilinx"
> LIC_FILES_CHKSUM = "file://README.md;md5=d5750ae6496dd931669b454b5aaae2cd"
>
> -inherit distro_features_check
> +inherit distro_features_check update-alternatives
>
> -ANY_OF_DISTRO_FEATURES = "fbdev x11"
> +REQUIRED_DISTRO_FEATURES = "x11 fbdev wayland"
>
> PROVIDES += "virtual/libgles1 virtual/libgles2 virtual/egl virtual/libgbm"
>
> @@ -40,22 +40,14 @@ PACKAGE_ARCH = "${SOC_FAMILY}"
>
> S = "${WORKDIR}/git"
>
> -X11RDEPENDS = "libxdamage libxext libx11 libdrm libxfixes"
> -X11DEPENDS = "libxdamage libxext virtual/libx11 libdrm libxfixes"
> +# If were switching at runtime, we need all RDEPENDS needed for all backends
> available
> +RDEPENDS_${PN} = " kernel-module-mali libxdamage libxext libx11 libdrm
> libxfixes"
I believe this will install x11 libs in images even if one doesn't have "x11" in
DISTRO_FEATURES. This is my case and I would not use the recipe like this. I
would argue that typical embedded systems will choose in advance which of the
variant (x11, wayland, fbdev, headless) would be used and to keep things tight,
would expect unused libs and components not to make it to the rootfs. The cues
in DISTRO_FEATURES should be honoured as was the case in the recipe right now.
>
> -RDEPENDS_${PN} = " \
> - kernel-module-mali \
> - ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '${X11RDEPENDS}', '',
> d)} \
> - "
> +# We dont build anything but we want to avoid QA warning build-deps
> +DEPENDS = "wayland"
Won't this cause wayland libs to be built and installed on systems which don't
even have "wayland" in their DISTRO_FEATURES? I'm pretty sure there's a way to
clear those QA errors. I think the bin_package.bbclass is what you want here.
Certainly it is my opinion that since the recipe doesn't configure or compile it
doesn't need any extra DEPENDS, only RDEPENDS are required. If you use
bin_package.bbclass (and in any case in fact) the current "do_compile" should be
replaced by:
do_untar_bins() {
# Extract the MALI binaries into workdir tar -xf
${WORKDIR}/mali/rel-v2018.3/r8p0-01rel0.tar -C ${S}
} addtask untar_bins after do_unpack before do_install
>
> -DEPENDS = "\
> - ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}
> \
> -
