Summary: | Xkl-1.0.gir causes a build error in vapigen | ||
---|---|---|---|
Product: | libxklavier | Reporter: | Takao Fujiwara <tfujiwar> |
Component: | General | Assignee: | Sergey V. Udaltsov <svu> |
Status: | RESOLVED FIXED | QA Contact: | Sergey V. Udaltsov <svu> |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Takao Fujiwara
2012-03-09 02:35:25 UTC
vapigen is trying to introspect X11 API which is obviously not introspectable. And X11 API will not be introspectable ever. How can you explain that to vapigen? I could hide xkl_engine_filter_events from introspection but I would not like to do it. Tried to add the (skip) attribute to that parameter. Could you please check from git? I tried the skip but it seems that way does not resolve the problem. % vapigen /usr/share/gir-1.0/Gkbd-3.0.gir --library gkbd \ --pkg gtk+-3.0 --pkg glib-2.0 --pkg gmodule-2.0 Xkl-1.0.gir:877.54-877.54: error: The type name `X.XEvent' could not be found <type name="xlib.XEvent" c:type="XEvent*" skip="1"/> ^ I don't know if Xkl-1.0.metadata can resolve this. http://live.gnome.org/Vala/Bindings I mean the change does not resolve this problem. --- Xkl-1.0.gir.orig +++ Xkl-1.0.gir @@ -871,7 +871,7 @@ <type name="gint" c:type="gint"/> </return-value> <parameters> - <parameter name="evt" transfer-ownership="none"> + <parameter name="evt" transfer-ownership="none" skip="1"> <doc xml:whitespace="preserve">delivered X event</doc> <type name="xlib.XEvent" c:type="XEvent*"/> </parameter> I guess it is a bug in vapigen then - it should ignore the parameters marked as "skip", according to the introspection docs: http://live.gnome.org/GObjectIntrospection/Annotations (skip) used to indicate that the parameter or return value is only useful in C and should be skipped (bug) What do you think? OK, it seems this problem can be fixed by Xkl-1.0.metadata # cat Xkl-1.0.metadata Xkl cheader_filename="libxklavier/xklavier.h" Engine.filter_events.evt ref type="X.Event" # vapigen /usr/share/gir-1.0/Gkbd-3.0.gir --library gkbd --metadatadir=. \ --pkg gtk+-3.0 --pkg glib-2.0 --pkg gmodule-2.0 It might be good if libgnomekbd could provide gkbd.vapi. Currently I generate gkbd.vapi during the ibus build. > It might be good if libgnomekbd could provide gkbd.vapi. Currently I generate
> gkbd.vapi during the ibus build.
I do not mind, if that is the standard practice for gnome libraries. What do other libraries do in relation to vapi?
(In reply to comment #8) > > It might be good if libgnomekbd could provide gkbd.vapi. Currently I generate > > gkbd.vapi during the ibus build. > I do not mind, if that is the standard practice for gnome libraries. What do > other libraries do in relation to vapi? The vala files are maintained as source codes only. 'valac --ccode' can convert the vala files to C files. e.g. % cat Xkl-1.0.metadata Xkl cheader_filename="libxklavier/xklavier.h" Engine.filter_events.evt ref type="X.Event" % cat Gkbd-3.0.metadata Configuration cheader_filename="libgnomekbd/gkbd-configuration.h" % vapigen /usr/share/gir-1.0/Gkbd-3.0.gir --library gkbd --metadatadir=. \ --pkg gtk+-3.0 --pkg glib-2.0 --pkg gmodule-2.0 % ls a.vala gkbd.vapi Xkl-1.0.metadata Gkbd-3.0.metadata % cat a.vala using Gkbd; private Gkbd.Configuration m_config = null; public static int main (string[] argv) { m_config = Gkbd.Configuration.get(); return 0; } % valac --vapidir . \ --pkg gkbd --pkg gtk+-3.0 --pkg gmodule-2.0 --pkg Xkl-1.0 \ --metadatadir . --ccode \ a.vala % ls a.c a.vala gkbd.vapi Xkl-1.0.metadata Gkbd-3.0.metadata Ok, feel free to submit the patch (In reply to comment #10) > Ok, feel free to submit the patch The patch has ever been submitted? If nobody minds I can file a slightly modified version (for Caribou) to vala itself, which might make more sense because libxklavier wouldn't need extra dependency to vapigen. (In reply to comment #11) > (In reply to comment #10) > > Ok, feel free to submit the patch > > The patch has ever been submitted? If nobody minds I can file a slightly > modified version (for Caribou) to vala itself, which might make more sense > because libxklavier wouldn't need extra dependency to vapigen. Great. I'm a bit busy to work on it. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.