On Mon, Jun 28, 2010 at 6:41 PM, Daniel Hams <daniel.h...@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. _______________________________________________ rhythmbox-devel mailing list rhythmbox-devel@gnome.org http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
