Greg Troxel <[EMAIL PROTECTED]> writes:
> An easier approach is to put in the if, but with *use-old-slib-init*,
> define that to #f, and put in NEWS to set that to #t if trouble. That
> gives people a low-grief way to recover, but without a lot of
> guile maintainer time.
Hmm. If there isn't an easy way to detect the SLIB version, then
that'd definitely be worth considering.
> I would expect that as long as the older slib version has the
> define->define-public hack then the guile.init that came with it
> define->would
> work fine.
Indeed. If I felt relatively certain that just calling
(load-from-slib "guile.init")
would do the right thing with the current SLIB version, then I'd be
inclined to consider that as a solution, even in 1.6.8, whenever we
detect a "newer" SLIB[1].
However, to have a good sense that loading guile.init *would* "do the
right thing", I or someone else probably needs to go through
guile.init with reasonable care, while consulting the current
slib.scm, to make sure the differences look "OK". My suspicion is
that much of guile.init is just fine, but there are some comments in
slib.scm that may warrant a bit of investigation.
If there's anyone else here who has the time and wants to attempt that
evaluation (and probably raise questions here), then that would be
great. Otherwise, I'll try to get to it soon, though it might not be
until this weekend at the earliest.
[1] Though actually, the current SLIB release still has the unix/UNIX
symbol case issue (which has been fixed in CVS). I believe it also
doesn't define the (ice-9 slib) module if it detects guile 1.6, so
we'd still need at least a small wrapper.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
