Re: A GNOME Bindings release set?

["muppet" <scott asofyet org>]

Mike Kestner said:
> On Tue, 2003-11-25 at 07:26, James Henstridge wrote:
>
>> I can't speak for other binding authors, but gnome-python can build when
>> only the Gnome development platform libraries are installed (things like
>> the gnome-print bindings are only built if gnome-print is present), so
>> they don't add any hard dependencies to the build.  I wouldn't be
>> surprised if other bindings are similar.
>
> This is how Gtk# does it.  We currently have conditional builds for
> gnome (which consists of lib(gnome|gnomecanvas|gnomeui)),
> gnomeprint(ui), gda, gnomedb, librsvg, and gst.

gtk-perl (the bindings for gtk 1.x and gnome 1.x) worked this way as well.  it
was fine for distro packagers, who could just add rpm dependencies on all the
requisite libraries, but was infuriating for anyone who tried to install the
package from CPAN.

gtk2-perl actually has what we consider reasonable granularity; libgnome and
libgnomeui are bound in the same package, but the libgnomecanvas bindings are
distributed separately, etc.  the basic rationale is "if it's useful without
all the other stuff, break it out."  e.g., the canvas and GConf are useful in
non-gnome apps.  we originally had everything in one great big package, but
the users complained.

this granularity actually forces us to be careful about our ABI and expose
reasonable interfaces for adding new extensions, which is mighty useful for
things such as interoperable bindings for non-published libraries.  it also
allows us to be sticklers for portability on the stuff that can run on windows
without annoying the maintainers of bindings for unix-only libs.

as a drawback we have a ton of packages on the sourceforge releases page.  you
win some, you lose some.

-- 
muppet <scott at asofyet dot org>