On Fri, Jul 26, 2013 at 10:13 AM, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > On Thu, 2013-07-25 at 00:08 -0300, jprvita at gmail.com wrote: >> From: Jo?o Paulo Rechi Vita <jprvita at openbossa.org> >> >> Support for BlueZ 4 is built only when bluez.pc is present on the target >> system, and that is a big hint that we should load the BlueZ 4 modules. >> On all other cases we can try to load the BlueZ 5 modules. >> --- >> configure.ac | 3 +++ >> src/daemon/default.pa.in | 9 ++++++++- >> 2 files changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/configure.ac b/configure.ac >> index a63cc82..d23e1aa 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -1008,6 +1008,9 @@ AS_IF([test "x$enable_bluez5" = "xyes" && test "x$HAVE_BLUEZ_5" != "x1"], >> AC_SUBST(HAVE_BLUEZ_5) >> AM_CONDITIONAL([HAVE_BLUEZ_5], [test "x$HAVE_BLUEZ_5" = x1]) >> >> +AS_IF([test "x$HAVE_BLUEZ_4" = "x1" || test "x$HAVE_BLUEZ_5" = "x1"], HAVE_BLUEZ=1) >> +AC_SUBST(HAVE_BLUEZ) >> + >> #### UDEV support (optional) #### >> >> AC_ARG_ENABLE([udev], >> diff --git a/src/daemon/default.pa.in b/src/daemon/default.pa.in >> index 19dd8a6..4130c7a 100755 >> --- a/src/daemon/default.pa.in >> +++ b/src/daemon/default.pa.in >> @@ -84,16 +84,23 @@ load-module module-detect >> load-module module-jackdbus-detect channels=2 >> .fail >> .endif >> +ifelse(@HAVE_BLUEZ@, 1, [dnl >> >> -ifelse(@HAVE_BLUEZ_4@, 1, [dnl >> ### Automatically load driver modules for Bluetooth hardware >> .ifexists module-bluetooth-policy at PA_SOEXT@ >> load-module module-bluetooth-policy >> .endif >> +ifelse(@HAVE_BLUEZ_4@, 1, [dnl >> >> .ifexists module-bluez4-discover at PA_SOEXT@ >> load-module module-bluez4-discover >> .endif >> +], [dnl >> + >> +.ifexists module-bluez5-discover at PA_SOEXT@ >> +load-module module-bluez5-discover >> +.endif >> +])dnl >> ])dnl >> >> ifelse(@HAVE_AF_UNIX@, 1, [dnl > > As discussed in IRC, we should load module-bluetooth-discover in > default.pa instead of the version specific modules. > I think I managed to find a solution that will make everyone happy: after changing the prefix of the BlueZ 4 support to pa_bluez4_ and with a few more changes, like separating the paths of the org.bluez.MediaEndpoint objects, the BlueZ 4 and BlueZ 5 modules can run side-by-side. So basically module-bluetooth-discover can load each module-bluez?-discovery.so it finds installed. To check for installed modules I'm using access() and the pathname is contructed using lt_dlgetsearchpath() in the exact same way ".ifexists" in default.pa does. So "load module-bluetooth-discover" is equivalent to the following piece of default.pa: .ifexists module-bluez5-discover.so load-module module-bluez5-discover .endif .ifexists module-bluez4-discover.so load-module module-bluez4-discover .endif I think that's both suitable for developers, to ease testing both BlueZ versions, and distros that want to provide an upgrade path from BlueZ 4 to BlueZ 5. If only one version of BlueZ support is installed then module-bluetooth-discover will only try to load that module, avoiding having unused code loaded in memory. The load of module-bluetooth-discover can also be avoided if it impacts load time in some use cases by changing module-bluetooth-discover to the desired module-bluez?-discover in default.pa. And last but not least, at some point we may want to kick out this wrapping mechanism in favor of supporting BlueZ 5 only by default. -- Jo?o Paulo Rechi Vita http://about.me/jprvita
