On Sun, Apr 26, 2015 at 2:57 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Thu, 2015-04-23 at 17:38 +0300, Cristian Iorga wrote:
> > As BlueZ5 will be the default Bluetooth stack,
> > don't exclude it from world builds.
> >
> > Signed-off-by: Cristian Iorga <cristian.io...@intel.com>
> > ---
> > meta/recipes-connectivity/bluez5/bluez5.inc | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> > index 67aafbb..bf845a8 100644
> > --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> > +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> > @@ -100,5 +100,3 @@ FILES_${PN}-dbg += "\
> > RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
> >
> > SYSTEMD_SERVICE_${PN} = "bluetooth.service"
> > -
> > -EXCLUDE_FROM_WORLD = "1"
>
> The reason this is there is to ensure that a bitbake world doesn't build
> bluez4 and 5 at the same time. Even though v4 is moving to meta-oe, it
> doesn't change the fact we really need this so world builds don't end up
> in a mess.
>
> Typically, any recipe providing a vritual/xxxx PROVIDES will also end up
> with an EXCLUDE_FROM_WORLD as the dependency mechanism will then pull in
> the correct thing(s).
>
> Not ideal but its what we have today.
Originally, world was designed to only build one of any given multiple
provider situation, IIRC. Is that not the case, or is it the fact that both
get pulled in via dependencies in a world build, not directly?
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
