[OE-core] [PATCH v5 4/4] bluez5: don't exclude from world builds

[Christopher Larson]

On Mon, Apr 27, 2015 at 12:13 AM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Sun, 2015-04-26 at 18:17 -0700, Christopher Larson wrote:
> >
> > On Sun, Apr 26, 2015 at 2:57 PM, Richard Purdie
> > <richard.purdie at 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.iorga at 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?
>
> I'm not aware of any code that would remove things with multiple
> providers from world? Its possible that got lost when we switched to
> multiple threads of execution but that was a long time ago.


8262012a90273a4726ebaaf5c4da61262542e69d in bitbake added the initial
'world' implementation, which didn't do such a removal, but did explicitly
skip virtual/*, and it looks like aff3227b5e4a3dee9bceb120aac11f4bf3ac6409
implemented the first naive handling of it, beyond the virtual/ prefix,
from a quick perusal of bitbake history. It skipped the non-preferred
selections of every multiple provider.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150427/28a7a26a/attachment-0002.html>