> Date: Sat, 24 Nov 2018 22:20:33 -0800 > From: Chris Hanson <c...@chris-hanson.org> > > 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.) _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
