[oe] [meta-qt5][master][jethro][PATCH] qtconnectivity, qtsystems: fix bluetooth support

[Martin Jansa]

On Mon, Jan 04, 2016 at 05:39:39PM +0100, Javier Viguera wrote:
> On 04/01/16 17:17, Martin Jansa wrote:
> >
> > Is it deterministic?
> >
> > Will it always pick bluez4 when BLUEZ is set to bluez4, but there is
> > bluez5 is already in the sysroot as well?
> 
> No, BLUEZ is set by *bluetooth* class depending on your distro features 
> and is only used to add 'bluez4' or 'bluez5' to the recipe build-time 
> dependences (DEPENDS). But apart from that it does nothing to the QT5 
> compilation itself.

That's not what I was asking about.

Some distros are still using bluez4, you can try it as well with:
DISTRO_FEATURES_remove = "bluez5"
DISTRO_FEATURES_append = " bluez4"

But nothing prevents bluez5 from being populated in the sysroot, because
unlike bluez4 in meta-oe, bluez5 in oe-core doesn't set the PNBLACKLIST
the make these 2 recipes really mutually exclusive in sysroot.

So you can build both with:
bitbake -c build bluez5 bluez4
(or with "bitbake world")

and you end with 2 providers for bluez.pc (and bluetooth.so) in the sysroot
and qtconnectivity will get runtime dependency on whatever bluez version
was built first, e.g. bluez5 even when BLUEZ variable says bluez4. See
shlibs provider code in package.bbclass.

That's cause for undeterministic builds and this QA warning:
WARNING: QA Issue: qtconnectivity rdepends on bluez5, but it isn't a build dependency? [build-deps]

> 
> >
> > config.tests/bluez/bluez.pro is only using pkgconfig to find bluez, so
> > I'm not sure which one will win.
> 
> Neither do I, but I don't think having both versions of the bluez 
> libraries in the sysroot is a common use-case. The package config file 
> for bluez4 and bluez5 is almost the same. It adds the same cflags and 
> libs to any package querying it:
> 
> Libs: -L${libdir} -lbluetooth
> Cflags: -I${includedir}
> 
> So to recap: this change fix the bluetooth support which is currently 
> broken because QMAKE_CACHE_EVAL is not used at all, and also allows to 
> build QT5 bluetooth support using bluez5 instead of the hard-coded bluez4.

I understand that, but it adds bluez5 support with undeterministic
behavior, which can cause currently bluez4 only images to get bluez5
dependency through qtconnectivity, as uncommon such setup it could be
it's still an issue (which should be fixed eithr in oe-core or meta-qt5).

Maybe I should PNBLACKLIST bluez4 only recipes with message that they
will be removed from meta-oe after 2.1 release and stop caring about
issues like this.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20160104/6e99f571/attachment-0002.sig>