GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Basically it would be nice if the gir was usable with vala, currently a couple of errors are thrown:
[fabiand@apu tests]$ ls
Makefile.include test-redis-client.c vredis.vala vredis.vala~
[fabiand@apu tests]$ cat vredis.vala
// var client = Redis.Client();
[fabiand@apu tests]$ valac --verbose --girdir=.. --pkg Redis-1.0 vredis.vala
Loaded package `/usr/share/vala-0.16/vapi/glib-2.0.vapi'
Loaded package `/usr/share/vala-0.16/vapi/gobject-2.0.vapi'
Loaded package `../Redis-1.0.gir'
Loaded package `/usr/share/gir-1.0/GLib-2.0.gir'
Loaded package `/usr/share/gir-1.0/GObject-2.0.gir'
Loaded package `/usr/share/gir-1.0/Gio-2.0.gir'
Gio-2.0.gir:44356.7-44356.47: warning: Virtual method `G.Resolver.lookup_service_async' conflicts with method of the same name
Gio-2.0.gir:46096.7-46096.31: warning: Signal `G.Settings.change_event' conflicts with method of the same name
(valac:10800): GLib-CRITICAL **: g_str_has_suffix: assertion `str != NULL' failed
** (valac:10800): CRITICAL **: vala_gir_parser_node_lookup: assertion `name != NULL' failed
Gio-2.0.gir:59053.7-59057.24: error: `UnixSocketAddress' already contains a definition for `abstract'
Gio-2.0.gir:58925.7-58927.103: note: previous definition of `abstract' was here
Compilation failed: 1 error(s), 2 warning(s)
[fabiand@apu tests]$ rpm -q glib2
[fabiand@apu tests]$ rpm -q vala
I, too, would love this to work. I haven't yet figured out how to fix that. I think it is a bug in Vala since I don't actually use either of those classes (they simply come from Gio-2.0).
I just talked to someone from #vala, and they suggested using --pkg gio-2.0 to prevent valac from using the Gio-2.0.gir.
Let me know if that helps.
As Christian said, the solution is to pass --pkg gio-2.0 to valac.
The reason for this is that Redis-1.0.gir includes Gio-2.0.gir, which Vala can't parse properly without additional metadata and a custom vala file. There are lot of reasons why this is the case, many of which are listed in the Generating a VAPI from a GIR section of the Upstream Guide on the Vala wiki. While both the Vala and GObject Introspection teams are working to resolve these issues, it is unlikely that all of these issues will ever be resolved.
In order to prevent valac from parsing the GIO GIR, you simply have to get valac to parse the GIO VAPI (which is generated from the GIR with the help of the files I mentioned above, and shipped with valac) first. Once it does so, the gio-2.0 package will have been provided, and when valac looks at Gio-2.0.gir and sees a package element for gio-2.0 it will know to ignore the rest of the GIR).
So, if you ever see errors from valac referring to a GIR for which a VAPI exists, the first thing you should try is asking valac to parse the corresponding VAPI.
An easy thing to do is then, to generate - additionally to the gir - a vapi for redis-glib using vapigen.
When I tried
vapigen --lib redis-1.0 --pkg gio-2.0 Redis-1.0.gir
I noted that vapigen interpretes ClientError as a n enum, and not es error.
It was mentioned that this shoudl work with a recent g-i version.
I'm not sure where you got that, but it's no different with git master of gobject-introspection. The issue is that the enum isn't registered with GType. You can use something like http://fpaste.org/yHVp/ to do that, or use glib-mkenums.
I'm usually pretty bad about creating gtypes for errors. Fixed in master.