[MIT-Scheme-devel] liarc build process updates

[Taylor R Campbell]

Before I begin, here is an extremely untidy archive of the modified
source tree I'm working with:
<http://people.csail.mit.edu/riastradh/tmp/liarc-boot.tar.bz2>.  It
should be possible to build that by entering the v7/src/ subdirectory
and running

% ./configure --enable-native-code=c
% make

I *almost* have everything cleanly building and installing
conveniently -- with dynamically loadable objects for edwin and
sf+compiler, so that the edwin.com, compiler.com, and all.com bands
work --, but the profusion of scripts scattered throughout the
directory tree has constantly been my undoing.  This script and that
script want to delete *-{unx,os2,w32}.* or *.c, and the other script
wants to install *.com, and nothing is consistent about .so and .dylib
(and .sl, and whatever else...) suffixes.

At the moment I've been piling kludge upon kludge to update the
scripts, but this isn't good enough to check in; it would be better to
have a principled, shared mechanism for all this.  But I'm a little
unsure of where it should all be organized: my understanding of the
existing build system is that the microcode is meant to be somewhat
separate from the rest of the system and able to be built on its own;
however, its static linking to the run-time system makes this
separation a bit difficult.

If I ignore this separation (as the current CVS does), I can make it
mostly work, except for the installation targets.  I had to fiddle
with the cleaning scripts to preserve `*.c' for a new `c-clean'
command/target, but I'm not sure how to transmit the information that
we need to install `*.dylib' or `*.so' instead of `*.com'.
(Provisionally, I altered the subdirectories' makefiles by hand either
to comment out the relevant lines or to substitute `*.dylib' for
`*.com', just to see whether I could make it work locally.)

Also, Edwin fails to start in the 6001 band (which I added another
dynamically loadable object for); I'm not sure why, and the only error
message is `Anomalous microcode error execute-manifest-vector -- get a
wizard'.  Does this subsystem matter much anymore, considering the age
of the installation of MIT Scheme in the `scheme' Athena locker
(although I may be updating this soon -- once the C back end installs
cleanly), and that 6.001 is no longer even using MIT Scheme?  (I don't
know myself whether it still matters -- perhaps there are other
classes still using it.)