> capi-network-bluetooth -> bluetooth-frwk ->bluez As defined in platform/core/api/bluetooth/CMakeLists.txt, capi-network-bluetooth has declared build dependencies on dlog, glib-2.0, capi-base-common, and bluetooth-api. dlog and glib are upstream, and capi-base-common as a build dependency is a set of headers. So, in character graphics, capi-network-bluetooth |---dlog (libdlog) |---glib-2.0 (libglib) |---capi-base-common (headers only) |---bluetooth-api
bluetooth-api is defined as a library in platform/core/connectivity/bluetooth-frwk/bt-api/CMakeLists.txt (line 77, ADD_LIBRARY(bluetooth-api...)), so I suppose it is part of bluetooth-frwk. However, build dependencies in CMakeLists.txt and in bluetooth-api.pc.in do not include bluez. In bluetooth-api.pc.in, they include dlog, dbus-glib-1, and vconf; CMakeLists.txt further adds gobject-2.0, gmodule-2.0, libxml-2.0, and syspopup-caller. Again, none of these are bluez: capi-network-bluetooth |---dlog (libdlog) |---glib-2.0 (libglib) |---capi-base-common (headers only) |---bluetooth-api | |---dlog (libdlog) | |---dbus-glib-1 (dbus-glib) | |---gobject-2.0 (libgobject) | |---gmodule-2.0 (libgmodule) | |---vconf | | |---gobject-2.0 (libgobject) | | |---glib-2.0 (libglib) | | |---dlog (libdlog) | | |---vconf-internal-keys (headers only) | |---libxml-2.0 (libxml2) | |---syspopup-caller | |---|---(etc., etc.) I notice now that bt-api/CMakeLists.txt does also define a few executions of dbus-binding-tool, to include ./bt-gatt.xml. bt-gatt.xml defines its interface name as org.bluez.Watcher. One can reasonably conclude that bluetooth-api is in conversation with bluez via dbus, based on content of bt-gatt.xml parameter to dbus-binding-tool in CMakeLists.txt. Inspecting source of platform/core/connectivity/bluetooth-frwk/bt-api/bt-hdp.c also reveals calls to dbus_message_new_method_call(BT_BLUEZ_NAME,...), for which BT_BLUEZ_NAME is org.bluez. Several other file locations in bt-api also define constants for various values of org.bluez.*. Presuming those code paths are executed, bluetooth-api has a functional dependency on bluez via dbus. Sorting out the build and functional dependencies is looking like a time-consuming and tedious process, but one that would be ultimately important for anyone wishing to extend the system. Steve Gerken ------------------- Linux Developer MSX, as broker for Jaguar Land Rover One World Trade Center, 121 SW Salmon Street, 11th Floor, Portland, Oregon, 97204 Email: [email protected] On 19 November 2013 08:40, Ylinen, Mikko <[email protected]> wrote: > > > > On Tue, Nov 19, 2013 at 6:08 PM, Gerken, Stephen < > [email protected]> wrote: > >> Hi all, >> >> > Are you looking for dependency chains from a web api down to hardware >> level? >> >> Ideally, yes, although getting that's increasingly looking like an >> unrealistic goal; for example, tizen.bluetooth >> (libwrt-plugins-tizen-bluetooth-impl.so) has build dependency chains like: >> tizen.bluetooth -> capi-network-bluetooth -> bluetooth-api -> >> syspopup-caller -> aul -> rua -> db-util -> sqlite3 >> and that's not even into the kernel yet. Just getting dependencies >> understood to the level of upstream sources looks like a significant >> undertaking all by itself. >> > > Visualizing the dependencies would be great indeed. However, there's no > officially supported tool > at the moment. This might be interesting though > https://lists.tizen.org/pipermail/ivi/2013-July/000653.html > > >> Interestingly, tizen.bluetooth doesn't have a direct dependency on bluez; >> is that interaction via dbus? >> > > capi-network-bluetooth -> bluetooth-frwk -> bluez. > > -- Mikko > > >
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
