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.
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.
--
Regards,
Javier Viguera
--
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
