[oe] [meta-oe][PATCH] packagegroup-tools-bluetooth.bb: Selects the tools appropriate for the version of bluez being used.

[Christopher Larson]

On Mon, May 2, 2016 at 8:54 PM, Ann Thornton <ann.thornton at nxp.com> wrote:

> Signed-off-by: Ann Thornton <ann.thornton at nxp.com>
> ---
>  .../packagegroups/packagegroup-tools-bluetooth.bb  | 40
> ++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 meta-oe/recipes-connectivity/packagegroups/
> packagegroup-tools-bluetooth.bb
>
> diff --git a/meta-oe/recipes-connectivity/packagegroups/
> packagegroup-tools-bluetooth.bb
> b/meta-oe/recipes-connectivity/packagegroups/
> packagegroup-tools-bluetooth.bb
> new file mode 100644
> index 0000000..bdab389
> --- /dev/null
> +++ b/meta-oe/recipes-connectivity/packagegroups/
> packagegroup-tools-bluetooth.bb
> @@ -0,0 +1,40 @@
> +# Copyright (C) 2014-2015 Freescale Semiconductor
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM =
> "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
> +
> file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
> +
> +SUMMARY = "Set of Bluetooh related tools for inclusion on images"
>

Typo: Bluetooh


> +DESCRIPTION = "Add bluetooth tools based on the version of BlueZ in use.\
> +The tools that have been tested and work the best are pulled in \
> +automatically.  The same packagegroup can be used in a recipe without \
> +the need to know which version of BlueZ is in use. \
> +Supports BlueZ4 and BlueZ5."
>

This is more a description of the recipe than the package, but this ends up
in the package. This should describe what the purpose of the package is,
not how it's implemented. "Tools" is also rather vague here. Which tools,
for what purpose?


> +inherit packagegroup
> +
> +BLUEZ4_INSTALL = " \
> +    obexftp \
> +"
> +
> +BLUEZ5_INSTALL = " \
> +     bluez5-noinst-tools \
> +     bluez5-obex \
> +     bluez5-testtools  \
> +     libasound-module-bluez \
> +     ${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio',
> "pulseaudio-module-bluetooth-discover \
> +
> pulseaudio-module-bluetooth-policy \
> +
> pulseaudio-module-bluez5-discover \
> +
> pulseaudio-module-bluez5-device \
> +
> pulseaudio-module-switch-on-connect \
> +
> pulseaudio-module-loopback", \
> +                                             '', d)} \
>

This "_INSTALL" naming is a bit odd -- this isn't an image. These are
runtime dependences, not lists of packages to install. The difference is
subtle, but important. I'd suggest renaming those variables.

+# Install either bluez4 or bluez5 if they are in distro.
> +# Otherwise install nothing.
> +RDEPENDS_${PN} = " \
> +     ${@bb.utils.contains('DISTRO_FEATURES', 'bluez5',
> '${BLUEZ5_INSTALL}', "", d)} \
> +     ${@bb.utils.contains('DISTRO_FEATURES', 'bluez4',
> '${BLUEZ4_INSTALL}', "", d)} \
> +"


I'd suggest inheriting bluetooth and using the BLUEZ variable which is
already set to 'bluez5' or 'bluez4' based on the distro features.
RDEPENDS_${PN} = "${RDEPENDS_${BLUEZ}}" would work, if you defined the
variables as RDEPENDS_bluez4 and RDEPENDS_bluez5, for example. bitbake can
handle nested variable references. Anyone else want to weigh in on this?
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics