On 06/15/2015 07:52 PM, Burton, Ross wrote:
On 11 June 2015 at 10:08, Robert Yang <liezhi.y...@windriver.com
<mailto:liezhi.y...@windriver.com>> wrote:
The BLUEZ is default to bluez5, but there is only PACKAGECONFIG[bluez4],
no PACKAGECONFIG[bluez5], and the current version of libpcap (or the
higher version 1.7.3) only supports bluez4, we can't use
${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
for PACKAGECONFIG any more since BLUEZ is default to bluez5, and not
supported, and there is no bluez4 in oe-core any more, set PACKAGECONFIG to
""
by default, other layers where bluez4 is available can enable it via
bbappend.
So the point of this logic is that simply removing bluez5 from DISTRO_FEATURES
results in bluez4 being enabled where relevant, which you're removing.
Would a better fix would be to have a dummy (empty) bluez5 stanza?
Hi Ross,
The code was:
PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
'${BLUEZ}', '', d)}"
PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
BLUEZ is default to bluez5, did you mean that we add a line like:
PACKAGECONFIG[bluez5] = ",,"
or
PACKAGECONFIG[bluez5] = ",--disable-bluetooth,"
But we didn't need such a line, since when PACKAGECONFIG != bluez4, the
--disable-bluetooth will be used.
Maybe we can simply drop this patch ? I made this patch to avoid confusing
the user.
// Robert
Ross
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
