Re: [Vala] .typelib support in Vala

[Evan Nemerson <evan coeus-group com>]

On Thu, 2012-08-30 at 21:59 -0007, Jim Nelson wrote:
> Last year there was some discussion on the list about Vala's .gir
> support
> (https://mail.gnome.org/archives/vala-list/2011-April/msg00003.html).
>  Jürg said that Vala only reads the XML (.gir files) and not
> the .typelib files.
>
> My question is, how should a developer deal with a situation where a
> library distributes a .gir (usable by valac) but the .gir references a
>  namespace that's only available as a .typelib.

If it is truly only available as a typelib you're basically out of luck.
That's a bit like asking how a developer should deal with a situation
where they need to compile some C against a library but the library
doesn't install header files.

Sometimes you may have to install an extra package, but the GIRs should
be available.

> Because the .gir naming convention is CamelCase and not the same as
> Vala's lower-and-dashes, valac can't even find the VAPI and
> compilation fails.  In my case, I'm seeing this:

You should pass the pkg-config names of whatever dependencies you need
to valac.  valac will parse those VAPIs first, and there is an
annotation which will tell valac what GIR namespace the Vala namespace
corresponds to.  For example, gio-2.0 has this:

[CCode (cprefix = "G", gir_namespace = "Gio", gir_version = "2.0",
lower_case_cprefix = "g_")]

> error: Package `GLib-2.0' not found in specified Vala API directories
> or GObject-Introspection GIR directories
> error: Package `GObject-2.0' not found in specified Vala API
> directories or GObject-Introspection GIR directories

This is disconcerting.  glib-2.0 and gobject-2.0 should be included
automatically, so valac should never try to look for GLib-2.0 or
GObject-2.0.  What version of valac are you using?  If you are using
GIRs directly you should be using at least vala-0.16.

> error: Package `Gio-2.0' not found in specified Vala API directories
> or GObject-Introspection GIR directories

--pkg gio-2.0 should fix this.

> There is a workaround: I can create hard links for the VAPIs
> (glib-2.0.vapi -> GLib-2.0.vapi, etc.), but I can't expect our users
> to do the same when they build our tarball.