On Fri, Nov 11, 2011 at 9:49 PM, Alon Bar-Lev <alon.barlev@xxxxxxxxx> wrote: > On Sat, Nov 12, 2011 at 1:42 AM, Lucas De Marchi > <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >>> If you do not expose the plugin.h (install it as part of bluez package >>> installation), >>> it means that all plugins must be in tree. >>> Or you require people to checkout bluez sources and compile against >>> it, this is none standard approach. >>> Same for other header files which may be used by out of tree plugins. >> >> The goal here is not to be able to build out of tree, but just as >> module or builtin. > > <snip> > >> Then this is a bug and should be treated as such. In ConnMan/oFono we >> prefix the functions and then we use a glob in the linker script. I >> think we don't have that in bluez because there aren't that many >> external plugins. > > Well, so there will be no out of tree plugins. > So what is the process to get complex module such as sixaxis into tree? Resolve the issue with a few symbols that should be exported. Maybe we would need to start using prefixes like ofono/connman do. Just patching the version script IMO is not a good thing ( e.g. in the mail thread you mentioned, dbus_connection_unref() and dbus_bus_get() are not right. If you need those you should link against d-bus instead when building as an external module ) > > Adding the udev dependency to bluetoothd is ugly. > Bloating the bluetoothd with a lot of more code is ugly. > So at the very least the symbol issues should be resolved, so the plugin can > be built into its own .so. Correct. Patches for that would be appreciated. Regards, Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
