(in)stability / parallel installs / platform-2.7.93

[Andy Wingo]

Hey all.

[ Longer email. I would appreciate comments from old hands at 
  packaging guile libraries for comments, or even new ones ;) ]

At some point, I'd like to jump on the GNOME platform bindings
bandwagon. It would give us more visibility, leading to more users and a
better piece of software. But we have raise ourselves to the next level
before we can jump on.

Take a look at the rules:
http://developer.gnome.org/dotplan/bindings/rules.html

The bits about strict stability scared me at first. I mean, we don't
have a stable product, and I don't see a time in the future when we can
call it stable. We simply don't have enough hackers to probe all parts
of the API. That's not a reason to give up, though; the rules allow for
more frequent breaks in compatibility _iff_ the different versions are
parallel installable.

I've been working towards making this happen. Detailed below are various
aspects of parallel installability that need to be addressed. The latest
release linked to below implements all of the below, except versioned
pkg-config files.

API versions
============

Different versions of the API need to have identifying numbers. For
example, Gtk+ has a 2.0 series and a 1.2 series, where 2.0 and 1.2 are
the "API versions". Because the platform bindings are managed and
released as a unit, we can assign a single number to the whole of
guile-gnome-platform. 

That leaves us with the problem of what number to choose. We could
choose a version following the platform bindings version, e.g. 2.8, but
that would be confusing to require version 2.8 of the API, but rely on
features added in a hypothetical 2.10 release of the bindings which is
backwards-compatible with 2.8.

I think it makes more sense to decouple the version of the wrapped
platform from the version of the guile-gnome API. This number would
hopefully change much less frequently than platform bindings releases.
For now, we start with 0, which indicates that there is no stability
right now. When a stable release is made (either 2.8 or 2.10), we up it
to 1. Whenever the API changes in an incompatible way -- whether in
(gnome gobject), an incompatible change in argument types/arity for an
existing wrapped procedure, or removal of a procedure, we bump the API
version.

Making an incompatible change thus becomes possible, but still not
desirable, because as we will see each guile-gnome app will need to be
explicitly updated to use the new API version.

The load path
=============

In the context of multiple versions of an API installed, using the
(gnome gobject) module has no defined meaning. It is clear that
different modules will have to live in disjoint load paths, and that the
load path will have to be munged at load time to pick the right one.

I think that this can be done nicely with a wrapper script, e.g. for API
version 0 it would be `guile-gnome-0'. Running the script would set up
the guile load path as appropriate, and then exec guile, passing on all
of its arguments. A script written for guile-gnome-0 would then start
like this:

#! /bin/sh
exec guile-gnome-0 -s $0 "$@"
!#

This would find guile-gnome-0 in $PATH, which will munge the load-path
as appropriate, find guile itself in $PATH, and exec. Because the guile
modules can't actually be used from an unmunged guile, it doesn't make
sense to install them to $datadir/guile. Right now, I'm putting them in
$datadir/guile-gnome-$apiversion. 

Other files
===========

Requiring a wrapper script has the added ability to munge
LD_LIBRARY_PATH, so that g-wrapped libs can be put in
$libdir/guile-gnome-$apiversion. There's still a problem with the base
gobject wrapper (and corba as well), which are actually linked to. These
need to have their names munged, much like there is libgtk-1.2 and
libgtk-x11-2.0. I have $libdir/libguile-gnome-gobject-$apiversion.so.
Headers are likewise installed in versioned directories, which are
pointed to by the pkg-config files.

I'm not versioning info files right now. I'd like to avoid that, but
whatever. The only other problem now is pkg-config files.
Parallel-installed pkg-config files need to have different names, and
that sounds like automake pain, but it's probably necessary.

Release
=======

http://download.gna.org/guile-gnome/releases/guile-gnome-platform-2.7.93.tar.gz

Released off of my archive, address@hidden, which is
mirrored at http://ambient.2y.net/wingo/arch/address@hidden
I'll mirror and merge soon; otherwise if you catch my
guile-gnome-dists--dev--0, you can check out configs/wingo/platform to
hack on the latest. The -extra bindings haven't been updated yet.

OK, that covers it. Let me know any comments you have.

Cheers,
-- 
Andy Wingo <address@hidden>
http://ambient.2y.net/wingo/