[OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Tanu Kaskinen]

On Tue, 2015-04-07 at 15:02 +0200, Martin Jansa wrote:
> On Tue, Apr 07, 2015 at 03:46:06PM +0300, Tanu Kaskinen wrote:
> > On Tue, 2015-04-07 at 14:44 +0200, Martin Jansa wrote:
> > > On Tue, Apr 07, 2015 at 03:36:31PM +0300, Tanu Kaskinen wrote:
> > > > This would be more appropriate for recipes that only support bluez4:
> > > > 
> > > > #  inherit bluetooth
> > > > #  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
> > > > #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> > > 
> > > The last example isn't correct, because you still need to respect
> > > 'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ
> > > variable.
> > 
> > BLUEZ is empty if 'bluetooth' is not in DISTRO_FEATURES, so my example
> > should work fine.
> 
> The default value is, but that doesn't ensure that user has different
> value set in local.conf and suddenly his bluetooth-less distro
> configuration is trying to enable bluez* support in some component.
> 
> So for consistency sake you should respect bluetooth in DISTRO_FEATURES
> (like in the previous example).

I don't see any use case where it would make sense to set BLUEZ outside
bluetooth.bbclass. Do you? For simplicity reasons, my preference would
be to treat the BLUEZ variable as read-only outside bluetooth.bbclass
(and document it as such).

You're definitely right about being consistent, though - if we can
assume BLUEZ to be empty when 'bluetooth' is not in DISTRO_FEATURES,
then there's no point in checking DISTRO_FEATURES in the first example
either.

-- 
Tanu