Re: [Vala] Generating bindings for classes defined over multiple packages

[Jan Hudec <bulb ucw cz>]

On Mon, Feb 08, 2010 at 17:13:43 -0500, Gabe Gorelick-Feldman wrote:
> Thanks, but at that point it's easier just to do the binding by hand. I was
> trying to come up with a process that could integrate well with the build
> system, that way the library can be built and bindings can be
> auto-generated, but I guess that's not possible.

You have bigger problem than that. IIRC Vala does not yet support either
partial classes or extension methods. Thus it's not possible to have two
.vapi files contributing to one class, manually-written or generated.
So you'll have to generate two alternate .vapi files, one with and one
without Gtk and that should be possible to auto-generate.

Extension methods (C# has them as specially declared static methods anywhere,
but Vala could have other syntax) would be nice in Vala (since in C they are
just functions following the class' naming convention) but until they are
there, you'll have to do alternative packages.

> Are there any plans to make the vala tools less package-oriented? It would
> be nice if you could just give them some header files and the shared
> libraries they map to instead of having to package everything.

A "package" just means to write the .pc (pkg-config) file listing version,
compiler and linker flags and dependencies for the library. Just look up the
pkg-config manual; the format is really simple.

The main advantage of .pc files for vala is, that they provide necessary
options for compiler and linker, so you just tell valac the packages you need
and it can just give you compiled application.

And since each normally describes just one library, so it's not like you'd
need any better granularity. For example GLib is one "package" for
distribution, but installs glib-2.0.pc, gobject-2.0.pc and gio-2.0.pc
corresponding to libglib-2.0.so, libgobject-2.0.so and libgio-2.0.so
respectively and similarly for Gtk, which additionally installs "virtual"
gdk-2.0 and gtk+-2.0 packages that simply depend on the others.

Now you don't need to install the .pc file anywhere. Just export appropriate
variable (PKG_CONFIG_PATH) with the directory where to find the .pc files
when running the tools. On the other hand the shared libraries probably
are or will be installed (otherwise it wouldn't make sense to make them
shared, no?), so providing .pc files will benefit anybody who wants to use
them.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>