GNOME Bugzilla – Bug 677073
vapi version is tied to specific library version
Last modified: 2012-06-13 04:56:25 UTC
(I can't imagine I'm the first to find this issue, but I couldn't find an open bug). How do we solve the problem of .vapi files distributed with Vala being tied to a certain version of a library? My specific problem is with Vala 0.17 and GLib 2.30. I have code which subclasses GMount. This had a new method added in 2.32: g_mount_get_sort_key(). It's exposed in the .vapi from 0.16 onwards. So, with Vala 0.17 I get: error: `TestMount' does not implement interface method `GLib.Mount.get_sort_key' But if I implement it, I can no longer compile my code with older Vala versions, and ... I only have GLib 2.30 anyway, so my C code fails to compile: testmount.vala:32:7: error: 'GMountIface' has no member named 'get_sort_key' Is there a rule tying specific Vala versions to specific GLib versions? That seems a nasty kludge, and in fact we need to tie Vala version to a specific version of every library for which it contains bindings, which is really impractical. In C, I'd just use '#if GLIB_MINOR_VERSION >= 32' around my implementation. Could we use the GI 'version' attribute (see #669593) to do some sort of workaround for this problem?
OK, looks like this is already done in glib-2.0.vapi with: #if GLIB_2_32 <new API> #endif However, GLIB_2_32 seems to be a manually added hack ... so it would still be good to have a method for GI-generated bindings such as gio-2.0.vapi.
and, of course, a solution that would still work when GLib 2.34 is released :)
(In reply to comment #0) > (I can't imagine I'm the first to find this issue, but I couldn't find an open > bug). How do we solve the problem of .vapi files distributed with Vala being > tied to a certain version of a library? Most of the .vapi files distributed with Vala are bindings to libraries that follow the GLib/GTK+ scheme of making incompatible versions parallel installable (this implies new pkg-config name and thus, also new vapi name). There are exceptions such as libnotify which are painful, but that's mainly an upstream library issue. Bindings to libraries that constantly break API should not be distributed with Vala. > My specific problem is with Vala 0.17 and GLib 2.30. I have code which > subclasses GMount. This had a new method added in 2.32: g_mount_get_sort_key(). > It's exposed in the .vapi from 0.16 onwards. > > So, with Vala 0.17 I get: > > error: `TestMount' does not implement interface method > `GLib.Mount.get_sort_key' It's an API break to add abstract methods to an interface. However, GLib didn't break API: the get_sort_key is not abstract, it's an optional vfunc (virtual in Vala terminology). So we simply need to fix the bindings. You cannot implement get_sort_key if you still want to support GLib 2.30 (and don't want to use #if), but at least you can use your GLib 2.30 compatible code with GLib 2.32 as well.
commit 093217d72dd50a9561a56171e8fe7a018a792753 Author: Jürg Billeter <j@bitron.ch> Date: Wed May 30 10:25:35 2012 +0200 gio-2.0: Fix g_mount_get_sort_key binding Fixes bug 677073.
Thanks Jürg ! I reopened because the same fix is needed for GLib.Volume and GLib.Drive .. patch attached.
Created attachment 216041 [details] [review] Fix for GLib.Volume and GLib.Drive
commit f2d8b110677ec1a337d6733980e5b42ae192859d Author: Sam Thursfield <ssssam@gmail.com> Date: Tue Jun 12 21:54:15 2012 -0700 gio-2.0: make Drive and Volume get_sort_key method virtual