Re: [Rhythmbox-devel] Rhythmbox And Vala - Questions:

[Jonathan Matthew <jonathan d14n org>]

On Mon, Jun 28, 2010 at 6:41 PM, Daniel Hams <daniel hams gmail com> wrote:
> Hello List,
>
> I'm new to this so please excuse me if this isn't the right forum to
> discuss this. And sorry if some of these are stupid questions.
>
> I've been working on automating the creation of Rhythmbox Vala plugin
> bindings following some work Michal Hruby did, and have some general
> questions about Rhythmbox's expectations and future intentions vis a vis
> Vala.
>
> Vala bindings bug with script:
> https://bugzilla.gnome.org/show_bug.cgi?id=621246
>
> Now, putting aside the state of the current bindings script for a
> moment:
>
> (1) Does Rhythmbox ever intend to ship .vapi files that will allow
> compilation of out-of-tree plugins?
>
> Basically this would mean publishing a .pc, header files and the
> relevant .vapi files in the appropriate system locations

Yes, the next release (this friday) will install a pkg-config file, C
headers, and the current manually defined .vapi files. I've managed to
build a basic C plugin using only the installed files, but I haven't
tried anything with vala. I don't see any reason it wouldn't work, but
I don't know for sure that it does work.

> (2) Maintenance of the bindings - currently the Vala tools for
> automating the .vapi file generation (vapigen) are a little weak on
> automation - for example you must explicitly hide artefacts - which
> makes maintaining a plugin API rather a pain. What is needed for
> Rhythmbox to consider bindings generation maintainable?

If we're going to automatically generate bindings, it needs to be
truly automatic. That is, integrated into the build, with proper
dependencies, and with no manual post-processing. If we're committing
generated files into the git repository, something is wrong.

> Assuming we can get some patches to the Vala tools to "autohide" any
> newly added artefacts - would this make automation of binding generation
> satisfactory?

I don't really know what you mean by this, so I can't really give an answer.

> I'm guessing that the bindings regeneration (if automated) should be
> re-done based on a dependency with the librhythmbox-core library - if
> it's newer than some timestamp of the .vapi creation, we re-generate the
> bindings.
>
> (3) If auto-generation of the .vapi files is not considered feasible -
> what mechanism will be used to create / maintain them?
>
> I'm sure the devs have given this more thought than I have, and for the
> moment I'm a little unsure what's the best way to proceed.

So far, vala hasn't been a high priority, so I haven't really thought
about it much. I've generally been happy picking between C and Python
for plugins I write, and most external plugins are written in Python.

The overall approach we've been taking so far with bindings is to
generate them manually as required, until such time as automatic
generation works acceptably. If we're going to support multiple
languages, I think we're going to need to work acceptably. I've been
slowly working on getting gobject-introspection working, and it looks
like the various other pieces in pygobject and so on are all falling
into place too.