GNOME Bugzilla – Bug 728482
Fix name clashes when using introspection
Last modified: 2019-03-20 10:37:24 UTC
It would be nice to be able to use Gom with Vala. These patches enable initial generation of a Vapi file, but more overrides and/or introspection annotations will probably be needed to make the bindings 100% correct. It also needs Gom to install a pkg-config file, but that's another bug. Some Vala tests would be nice too. (First time using git-bz, I hope this works right...)
Created attachment 274649 [details] [review] vala: Add m4/vapigen.m4 Avoids hard dependency on vapigen by including the m4 locally
Created attachment 274650 [details] [review] vala: Add configure check for vapigen Minimum version is 0.20, it might work with older versions but I can't check
Created attachment 274651 [details] [review] vala: Add metadata file for VAPI generation Currently only renames "gom_filter_new_sql" constructor to "new_for_sql" to avoid a clash with the Filter.sql property. More overrides will probably be needed for correct vapi generation, however
Created attachment 274652 [details] [review] vala: Add Vapi generation to Makefile.include VAPI generation relies on introspection, so put this within the HAVE_INTROSPECTION conditional. This is probably a bit redundant as configure should already check this for us, but better safe than sorry.
Ah, didn't spot there's already a pkg-config file hidden in data/, ignore that bit :-)
I would really rather use the gobject-introspection support in Vala so that I don't need to ship this with gom. Which means fixing the not-so-introspectable code in gom, and maybe fixing bugs in vala.
Created attachment 286751 [details] [review] gom: Rename gom_filter_new_sql() to gom_filter_new_for_sql() To avoid a clash for introspected languages.
Comment on attachment 274651 [details] [review] vala: Add metadata file for VAPI generation Obsoleted by the patch that just renames the function instead.
I won't take any patches to add Vala support in gom itself. You can either add that to vala itself, or use Vala's gobject-introspection support. If there are any more clashes or API problems, please file new bugs (once this one is merged).
Review of attachment 286751 [details] [review]: ::: gom/gom-filter.h @@ +70,3 @@ GHashTable *table_map); GArray *gom_filter_get_values (GomFilter *filter); +GomFilter *gom_filter_new_for_sql (const gchar *sql, All the other public constructors are called gom_filter_new_foobar, rather than gom_filter_new_for_foobar. Maybe it would be better to instead rename the internal sql property? This would have the added benefit of not breaking the API.
(In reply to comment #10) > Review of attachment 286751 [details] [review]: > > ::: gom/gom-filter.h > @@ +70,3 @@ > GHashTable *table_map); > GArray *gom_filter_get_values (GomFilter *filter); > +GomFilter *gom_filter_new_for_sql (const gchar *sql, > > All the other public constructors are called gom_filter_new_foobar, rather than > gom_filter_new_for_foobar. > > Maybe it would be better to instead rename the internal sql property? If it's only supposed to be used internally, maybe we could move it to private headers instead (see also gom-resource-priv.h) > This would have the added benefit of not breaking the API. That's still breaking API but I see what you mean.
Created attachment 347397 [details] [review] gom: Rename gom_filter_new_sql() to gom_filter_new_for_sql() To avoid a clash for introspected languages.
Review of attachment 347397 [details] [review]: are we worried about abi? should we add an alias with (skip)?
(In reply to Christian Hergert from comment #13) > Review of attachment 347397 [details] [review] [review]: > > are we worried about abi? should we add an alias with (skip)? This is in the blockers for API changes, probably for a 0.4 API. There are quite a few other changes that we'd need to do first though.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gom/issues/1.