[Rhythmbox-devel] Rhythmbox And Vala - Questions:
- From: Daniel Hams <daniel hams gmail com>
- To: rhythmbox-devel gnome org
- Subject: [Rhythmbox-devel] Rhythmbox And Vala - Questions:
- Date: Mon, 28 Jun 2010 10:41:42 +0200
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
(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?
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'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.
Cheers,
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]