Re: Installing DBus interface files for services

On 13/01/15 08:08, Philip Withnall wrote:
On Tue, 2015-01-13 at 10:43 +0800, Cosimo Cecchi wrote:
I was wondering if there's any reason we typically don't install on
the system DBus XML interface files for services. On my system, I can
see a bunch of definitions in /usr/share/dbus-1/interfaces, but it's
by no means a complete list of all the services in the system.
Perhaps a GDBus automake snippet
could be installed by GLib which:
 1. Installs D-Bus XML interface files.
 2. Includes rules for building documentation and C/H files from them.

Be a bit careful with this. It's a good idea up to a point, but most
(all?) D-Bus services do not offer any particular guarantees about the
ABI of their D-Bus introspection XML.

Even if the D-Bus API itself remains stable (which is by no means a
given), anything that is sensitive to the order of items in the file is
potentially going to break (i.e. it's important that code generated from
a third-party D-Bus API has an ABI based on the name of the
signal/function/property, not its numeric position).

Similarly, if an API consumer generates extern C API from D-Bus
introspection XML, it's hard to ensure that symbols don't appear and
disappear in a way that does not depend deterministically on the API
consumer's own version, depending on the version of the source of the
introspection XML that it happened to be built against. This is why
telepathy-glib and telepathy-qt each ship their own copy of
telepathy-spec, rather than build-depending on an external copy.

If the consumer generates internal-only C functions from introspection
XML, looks them up by name (explicitly or via the linker), and does not
generate anything with an inherent order (enums), then you can probably
get away with it: the worst that can happen is failure to build because
the introspection XML is too old.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]