Greg Troxel <[EMAIL PROTECTED]> writes: > Here's the code snippet from ice-9/slib.scm, with use of load that > respects the prefix (NetBSD/pkgsrc puts things in /usr/pkg, not /usr). > > (define-module (ice-9 slib) > :export (slib:load > implementation-vicinity > library-vicinity > home-vicinity > scheme-implementation-type > scheme-implementation-version > make-random-state > <? <=? =? >? >=? > require) > :no-backtrace) > > ;; Load slib's init routine. > (load (string-append (assoc-ref %guile-build-info 'pkgdatadir) > "/slib/guile.init"))
I haven't had a chance to delve very deeply here, but I just grabbed the debian 3a2-2 tree, unpacked it, edited guile.init to fix the one case problem (UNIX -> unix), then symlinked the slib dir as ./slib into my guile 1.6 CVS checkout and tried this: $ ./pre-inst-guile guile> (load-from-path "slib/guile.init") guile> (require 'new-catalog) guile> (require 'fft) guile> fft #<procedure fft (ara)> guile> At least from this admittedly trivial test, ignoring ice-9/slib.scm and using the slib guile.init directly seems to work. So do we have any known arguments against just using slib's guile.init and submitting fixes upstream? -- 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-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user