RFC: How to organize guile-gnome

[Andreas Rottmann]

Hi!

[ gst-guile note: I just finished getting gst-guile compile and work
  (well, at least vorbisplay.scm does) with the g-wrap--rotty--0.2
  branch. I made a few fixes wrt. gstreamer 0.7.2 (API breakage) on
  the way. The code is available in the gst-guile--rotty--0.1
  branch. ]

I wonder how we best should organize the guile-gnome project,
considering the following:

1) All projects providing GNOME (i.e. GObject-based) bindings will
  share some build infrastructure

2) According to Murray's mail to address@hidden, the developer
   platform and stuff not part of it should/must be packaged
   independently (this applies to my libgda bindings, for instance).

3) It would be good IMHO for guile-gnome to be a one-stop shop for
   *all* GNOME related bindings; this would include gstreamer.

The above has led me to the conclusion that we need a setup for
dealing with the above. That could either be CVS modules (I think they
do something like this) or arch metaprojects (which I'd favor).

This way we could split the whole thing up into modules (e.g. gobject,
gtk, gda, gstreamer, vte, ...) which we can combine in several ways
into meta-projects like 

* guile-gnome (GNOME developer platform bindings) 
* guile-gnome-extra (other stuff like gda)
* gst-guile
* guile-gnome-all (all-in-one package). 

We'd just need to discuss how to organize the common build
infrastructure so that each we can easily combine the modules without
needing to duplicate parts of configure.ac, for example.

I think that such measures will be show quite a bit of benefit in the
future, when new GNOME releases include an extended set of developer
platform modules; we can then easily toss in the relevant binding
modules into the guile-gnome metaproject.

Regards, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.