[plt-scheme] slib packaging

MJ Ray <markj+0111 at cloaked.freeserve.co.uk> writes:
> Neil W. Van Dyke <neil at neilvandyke.org> wrote:
> > For SLIB use from within PLT, the current best approach for my needs
> > seems to be to use the standard "slibinit" collection and unpack the
> > latest SLIB in the PLT tree as "collects/slib".
> 
> Shouldn't there be one slib copy per system, probably in /usr/lib/slib or
> /usr/share/slib?  (I've not checked FHS on this one, hence the two options.)
  |||||||||||||||
  +++++++++++++++ would be correct I believe. assuming you believe
  that FHS is holy writ.

> Packaging a PLT-specific SLIB seems contradictory to me.  My Opinion Only.

Unfortunately, it can be necessary. SLIB, while a wonderful collection
of software, is...um..."environmentally sensitive". It does a lot of
magic at run-time, and if you don't want to invoke SLIB's run-time
magic (e.g. you're using it in compiled code) you've got to find other
ways to work with it.

I imagine that the interaction of PLT's module system and SLIB's
module system is the root of the PLT-specific SLIB install. It
certainly was part of my pain when getting S2[1] to stitch SLIB code into
a PLT-targetted source file.

david rush

[1] S2 is my Scheme preprocessor. It lexically mangles modules into a
    single source file for whole program compilation and
    optimization. PLT is one of the output targets 1) because I can,
    and 2) because then I only have to remember one module system.
-- 
Scheme: Because everything is a function.
	-- Anton van Straaten (the Scheme Marketing Dept from c.l.s)