Re: [MIT-Scheme-devel] [commit aafa6ac04] Initial draft of program to grovel over files looking for libraries.

[Taylor R Campbell]

> Date: Sat, 24 Nov 2018 22:20:33 -0800
> From: Chris Hanson <address@hidden>
> 
> The find-scheme-libraries! procedure is supposed to be called by an end
> user who has a bunch of libraries that they potentially want to import.
> It's not intended to be used during the import process, which works pretty
> much as you suggest, except that map from library name to pathname is
> created by a previous call to find-scheme-libraries!.

Stepping back a moment from file systems and on-disk vs in-memory
caches, can you summarize the usage model of this?

Here's some of the relevant operations that I want to be able to do,
illustrated with how a C system would do it (which obviously we don't
have to mimic but which serves as a conceptual reference that has seen
plenty of practical use) and how we do it currently in MIT Scheme
(which obviously we don't have to keep).  How would I do each of
these?  If this question doesn't make sense, what are the operations
that you have in mind instead of these?

1. Install a library somewhere, either in some system-wide sense or in
   for use in a specific project.

   (For a C system, this typically means putting its .h files in
   /usr/local/include and its .so files /usr/local/lib, or
   /home/riastradh/project/obj/destdir.amd64/usr/include and
   /home/risatradh/project/obj/destdir.amd64/usr/lib.

   For MIT Scheme we dump stuff ad hoc in
   /usr/local/lib/mit-scheme-$ARCH.)

2. Build/link/expand/analyze a program that draws from a set of
   libraries I installed somewhere.

   (For a C system, the compiler or static analyzer looks in
   /usr/include for .h files, and the linker in /usr/lib for .so
   files, or in /home/riastradh/project/obj/destdir.amd64/... if I
   specify -I/-L or --sysroot.

   For MIT Scheme we load libraries in /usr/local/lib/mit-scheme-$ARCH
   for their macro definitions, but only if (a) we load them by
   pathname or (b) they are named in optiondb.scm which we don't have
   any formal mechanism to update.)

3. Run a program I built that uses the libraries it was built with.

   (For a C system that uses libfoo, the loader looks in /usr/lib for
   libfoo.so, and maybe /usr/local/lib or /opt/local/lib if I
   specified -R at build-time or if I use the debugging hack
   LD_LIBRARY_PATH at runtime.

   For MIT Scheme we load libraries in /usr/local/lib/mit-scheme-$ARCH
   but only if (a) we load them by pathname or (b) they are named in
   optiondb.scm which we don't have any formal mechanism to update.)

(For an interactive system, steps 2 and 3 might be combined.  For a
statically linked system, or equivalently a dumped band (with no ffi
modules), there may be essentially no step 3.)