All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Tanu Kaskinen <tanu.kaskinen@linux.intel.com>
Cc: "openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
Date: Tue, 7 Apr 2015 14:44:58 +0200	[thread overview]
Message-ID: <20150407124458.GA22953@jama> (raw)
In-Reply-To: <1428410191.12283.32.camel@tkkaskin-mobl3.ger.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

On Tue, Apr 07, 2015 at 03:36:31PM +0300, Tanu Kaskinen wrote:
> (A friendly request: could you use interleaved posting style as
> described in the mailing list guidelines here:
> https://wiki.yoctoproject.org/wiki/Community_Guidelines )
> 
> On Tue, 2015-04-07 at 11:51 +0000, Iorga, Cristian wrote:
> > The only way this could be fixed is to remove the aforementioned guidelines..
> > Like I said, there are plenty of examples in the code.
> > Those packageconfigs where elaborated based on:
> > 1. if a package has support for both BlueZ versions;
> > 2. If not, usually only BlueZ 4 is supported;
> > 
> > Care to elaborate how I can fix them otherwise? I am open to suggestions.
> 
> Sure, I can give concrete suggestions. This one I already gave in my
> first mail:
> 
> # Use this with:
> #  inherit bluetooth
> #  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
> #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> #  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
> 
> When someone applies that example to a recipe that only supports one
> bluetooth implementation, then the example of course needs some
> adaptation, but that's ok. I think the example gives a clear enough idea
> how the BLUEZ variable is supposed to be used.
> 
> Note that if you anyway want to also give an example of how to deal with
> recipes that only support one bluetooth implmementation, I think this
> line should be changed:
> 
>   PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
> 
> The reason is that if the recipe only supports bluez4, for example, then
> PACKAGECONFIG should never include bluez5, but that line will put bluez5
> to PACKAGECONFIG if the distro's chosen bluetooth implementation is
> bluez5. I suppose that doesn't actually break anything, but I don't
> think it's a good idea to recommend adding garbage to PACKAGECONFIG.
> 
> 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.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  reply	other threads:[~2015-04-07 12:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-03 14:13 [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack Cristian Iorga
2015-04-03 14:13 ` [PATCH 1/5] bluez5: upgrade to 5.29 Cristian Iorga
2015-04-03 19:01   ` Jack Mitchell
2015-04-03 14:13 ` [PATCH 2/5] bluez: remove recipes collection Cristian Iorga
2015-04-03 14:13 ` [PATCH 3/5] maintainers.inc: remove info related to bluez4 Cristian Iorga
2015-04-03 14:13 ` [PATCH 4/5] upstream_tracking.inc: bluez4 removed from oe-core Cristian Iorga
2015-04-03 14:13 ` [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack Cristian Iorga
2015-04-05 21:40   ` Burton, Ross
2015-04-06  7:31     ` Iorga, Cristian
2015-04-06 12:57       ` Peter A. Bigot
2015-04-06 13:18         ` Otavio Salvador
2015-04-06 14:32           ` Iorga, Cristian
2015-04-06 21:21             ` Peter A. Bigot
2015-04-06 21:39               ` Christopher Larson
2015-04-06 23:41                 ` Peter A. Bigot
2015-04-14 13:28                   ` Burton, Ross
2015-04-14 15:38                     ` Christopher Larson
2015-04-15 15:05                       ` Burton, Ross
2015-04-07 10:55             ` Martin Jansa
2015-04-07 11:21               ` Iorga, Cristian
2015-04-07 12:35                 ` Martin Jansa
2015-04-07 10:27   ` Tanu Kaskinen
2015-04-07 11:23     ` Iorga, Cristian
2015-04-07 11:41       ` Tanu Kaskinen
2015-04-07 11:51         ` Iorga, Cristian
2015-04-07 12:36           ` Tanu Kaskinen
2015-04-07 12:44             ` Martin Jansa [this message]
2015-04-07 12:46               ` Tanu Kaskinen
2015-04-07 13:02                 ` Martin Jansa
2015-04-07 20:16                   ` Tanu Kaskinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150407124458.GA22953@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=tanu.kaskinen@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.