GNOME Bugzilla – Bug 671218
Unable to bind libguestfs api inspect_get_type
Last modified: 2015-02-07 16:57:13 UTC
Created attachment 208860 [details]
Source and generated .gir for libguestfs gobject bindings
I have written a gobject binding for libguestfs. I've attached the binding source .gir file to this bug. The binding is automatically generated due to the size of the libguestfs api, .
Libguestfs contains an api called inspect_get_type(), which is not bound correctly by gobject introspection. This appears to be the only api which is not bound correctly. Looking at the generated XML, I see:
whereas the very similar inspect_get_arch() generates:
and is correctly handled as a method of the Session class.
I assume that the problem with this particular api is that its name ends in _get_type(). As this is a binding for an existing library it is not possible to change the name without introducing an inconsistency.
The immediate cause here is MainTransformer._pair_function(), which is responsible for mapping functions to classes. It aborts matching on guestfs_session_inspect_get_type because it ends in _get_type:
def _pair_function(self, func):
"""Check to see whether a toplevel function should be a
method or constructor of some type."""
Created attachment 209016 [details] [review]
This patch works for me. However, please review it carefully because I'm not familiar with either this codebase or Python.
Comment on attachment 209016 [details] [review]
The patch looks good, but it needs a testsuite. Adding the one you ran into would be a good candidate, to verify that it actually works.
Created attachment 209086 [details] [review]
This updated patch includes the requested test. It also fixes a bug in the previous patch which broke the warning for methods called *_get_type() which didn't return GType.
Review of attachment 209086 [details] [review]:
You didn't have to add a new so/gir/ch set, you could have reused the existing one, but this looks great.
Actually my first version did re-use an existing set. I switched to adding a new one because I had to disable --warn-error, and I didn't want to disable it more widely than necessary.
I'm not familiar with this project. Is there anything else I need to do to ensure the patch makes it upstream?
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]