GNOME Bugzilla – Bug 659682
c-namespace problem with telepathy spec
Last modified: 2011-09-21 10:54:59 UTC
I'm trying to generate C code using gdbus-codegen from telepathy spec. But I have a small c-namespace issue. For example the "connection" dbus object is made of a main mandatory interface org.freedesktop.Telepathy.Connection and various optional interfaces like: org.freedesktop.Telepathy.Connection.Interface.Avatars I generate the code with: gdbus-codegen --c-generate-object-manager \ --c-namespace TpGDBus \ --generate-c-code _gen/tp-gdbus-connection \ --interface-prefix org.freedesktop.Telepathy \ <list of all xml files> The problem is that the GDBusObjectProxy subclass is called TpGDBusObjectProxy which does not contains "connection" in its namespace and so will conflict if I do the same for other objects like org.freedesktop.Telepathy.Account. I've tried to generate in another way: gdbus-codegen --c-generate-object-manager \ --c-namespace TpGDBusConnection \ --generate-c-code _gen/tp-gdbus-connection \ --interface-prefix org.freedesktop.Telepathy.Connection \ <list of all xml files> But then the problem is it generates that function: TpGDBusConnection *tp_gdbus_connection_object_get_ (TpGDBusConnectionObject *object);
(In reply to comment #0) > I'm trying to generate C code using gdbus-codegen from telepathy spec. But I > have a small c-namespace issue. > > For example the "connection" dbus object is made of a main mandatory interface > > org.freedesktop.Telepathy.Connection > > and various optional interfaces like: > > org.freedesktop.Telepathy.Connection.Interface.Avatars > > I generate the code with: > > gdbus-codegen --c-generate-object-manager \ > --c-namespace TpGDBus \ > --generate-c-code _gen/tp-gdbus-connection \ > --interface-prefix org.freedesktop.Telepathy \ > <list of all xml files> > > The problem is that the GDBusObjectProxy subclass is called TpGDBusObjectProxy > which does not contains "connection" in its namespace and so will conflict if I > do the same for other objects like org.freedesktop.Telepathy.Account. > > I've tried to generate in another way: > gdbus-codegen --c-generate-object-manager \ > --c-namespace TpGDBusConnection \ > --generate-c-code _gen/tp-gdbus-connection \ > --interface-prefix org.freedesktop.Telepathy.Connection \ > <list of all xml files> You most probably want --interface-prefix org.freedesktop.Telepathy.Connection. instead (e.g. with a trailing .). > But then the problem is it generates that function: > > TpGDBusConnection *tp_gdbus_connection_object_get_ (TpGDBusConnectionObject > *object); Just use the org.gtk.GDBus.C.Name annotation on the org.freedesktop.Telepathy.Connection interface. If you do not want to add this to the XML file (it could be that XML file is not under your control, e.g. installed by a package), just use the --annotate command-line option. For more details see the gdbus-codegen(1) man page: http://developer.gnome.org/gio/unstable/gdbus-codegen.html I think this bug can be closed, yes?
(In reply to comment #0) > and so will conflict if I > do the same for other objects like org.freedesktop.Telepathy.Account. ^^^^^^^ (I think you mean _interfaces_ here) Btw, if you intend to use the ObjectManager stuff, you want to use just a single invocation of gdbus-codegen(1) so the generated GDBusObject sub-type knows about _all_ the interfaces - otherwise you can't easily mix and match.
(In reply to comment #1) > (In reply to comment #0) > > I'm trying to generate C code using gdbus-codegen from telepathy spec. But I > > have a small c-namespace issue. > > > > For example the "connection" dbus object is made of a main mandatory interface > > > > org.freedesktop.Telepathy.Connection > > > > and various optional interfaces like: > > > > org.freedesktop.Telepathy.Connection.Interface.Avatars > > > > I generate the code with: > > > > gdbus-codegen --c-generate-object-manager \ > > --c-namespace TpGDBus \ > > --generate-c-code _gen/tp-gdbus-connection \ > > --interface-prefix org.freedesktop.Telepathy \ > > <list of all xml files> > > > > The problem is that the GDBusObjectProxy subclass is called TpGDBusObjectProxy > > which does not contains "connection" in its namespace and so will conflict if I > > do the same for other objects like org.freedesktop.Telepathy.Account. > > > > I've tried to generate in another way: > > gdbus-codegen --c-generate-object-manager \ > > --c-namespace TpGDBusConnection \ > > --generate-c-code _gen/tp-gdbus-connection \ > > --interface-prefix org.freedesktop.Telepathy.Connection \ > > <list of all xml files> > > You most probably want > > --interface-prefix org.freedesktop.Telepathy.Connection. > > instead (e.g. with a trailing .). With trailing dot, it does not take org.freedesktop.Telepathy.Connection > > But then the problem is it generates that function: > > > > TpGDBusConnection *tp_gdbus_connection_object_get_ (TpGDBusConnectionObject > > *object); > > Just use the org.gtk.GDBus.C.Name annotation on the > org.freedesktop.Telepathy.Connection interface. If you do not want to add this > to the XML file (it could be that XML file is not under your control, e.g. > installed by a package), just use the --annotate command-line option. gdbus-codegen \ --c-generate-object-manager \ --c-namespace TpGDBusConnection \ --generate-c-code _gen/tp-gdbus-connection \ --annotate "org.freedesktop.Telepathy.Connection" --key org.gtk.GDBus.C.Name --value FooBar \ --interface-prefix org.freedesktop.Telepathy.Connection \ <xml files> It says: gdbus-codegen: error: no such option: --value
(In reply to comment #2) > (In reply to comment #0) > > and so will conflict if I > > do the same for other objects like org.freedesktop.Telepathy.Account. > ^^^^^^^ > (I think you mean _interfaces_ here) > > Btw, if you intend to use the ObjectManager stuff, you want to use just a > single invocation of gdbus-codegen(1) so the generated GDBusObject sub-type > knows about _all_ the interfaces - otherwise you can't easily mix and match. Telepathy spec is divided into different type of objects. For example it makes no sense for a dbus object to implement both org.freedesktop.Telepathy.Connection and org.freedesktop.Telepathy.Account. Each object has a main org.freedesktop.Telepathy.Foo interface, and a list of org.freedesktop.Telepathy.Foo.Interface.BarX. If I genarate all in one, it will generate only one GDBusObjectProxy, but I need different one for accounts, connections, etc... no?
(In reply to comment #3) > It says: > gdbus-codegen: error: no such option: --value Gah, someone changed this without updating the man page. Just skip the --key and --value options, e.g. --annotate <anonname> <key> <value>. I'll update the man page.
(In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #0) > > > and so will conflict if I > > > do the same for other objects like org.freedesktop.Telepathy.Account. > > ^^^^^^^ > > (I think you mean _interfaces_ here) > > > > Btw, if you intend to use the ObjectManager stuff, you want to use just a > > single invocation of gdbus-codegen(1) so the generated GDBusObject sub-type > > knows about _all_ the interfaces - otherwise you can't easily mix and match. > > Telepathy spec is divided into different type of objects. (Nitpick: again, I think you mean interfaces - the word "object" traditionally means "instance of a type" or "instance of a class". I know the GObject docs and code also uses the term "object" loose in this way to mean class or type but that doesn't make it right. At least for D-Bus we should use the correct terminology.) > For example it makes > no sense for a dbus object to implement both > org.freedesktop.Telepathy.Connection and org.freedesktop.Telepathy.Account. > > Each object has a main org.freedesktop.Telepathy.Foo interface, and a list of > org.freedesktop.Telepathy.Foo.Interface.BarX. > > If I genarate all in one, it will generate only one GDBusObjectProxy, but I > need different one for accounts, connections, etc... no? No, you don't need different ones - just because it's possible to export an object that implements both Connection and Account it doesn't mean you should. Anyway, It doesn't really matter... it just seems like extra overhead to generate N x GDBusObject, GDBusObjectSkeleton, GDBusObjectProxy and GDBusObjectManagerClient sub-types.... and also have N x Makefile rules for each.
I see.. ok if that's how it was intended to use, it works for me :) Generated .c is 134k lines, though :)
Let's close invalid, my problem was that I wanted a different TpGDBusObjectProxy per kind of object (so TpGDBusConnectionObjectProxy, TpGDBusAccountObjectProxy, etc). But guess we can consider all just dbus objects with different interfaces on them. Thanks.
(In reply to comment #7) > Generated .c is 134k lines, though :) Yeah... the generated code is a bit excessive and overly verbose ... and also includes a bunch of docbook comments. But it beats writing the code by hand - I hope :-)