Re: [MIT-Scheme-devel] A tale of four builds.

[Taylor R Campbell]

   Date: Thu, 3 Oct 2013 13:55:36 -0700
   From: Matt Birkholz <address@hidden>

   I don't know about converting compile-svm.sh to a set of
   parallelizable makefile rules.  The need for Stage.sh makes it... not
   obvious to me.  My only example is the pair of scripts
   make-lairc-dist.sh and make-liarc.sh.

One thing we ought to be able to do is use different source and object
trees.  That way, we could have one object tree for a (cross-compiler)
toolchain, and one object tree for the target, and a single makefile
to regenerate everything.

However, until then, I think we ought to have one makefile for a
toolchain, say Makefile.boot, with rules like:

.PHONY: all
all: boot/toolchain.com
        # Get the bootstrap objects out of the way.  (This is a little
        # sleazy.  Could save them with Stage.sh, alternatively, or do
        # this outside of make.)
        $(MAKE) clean

boot/toolchain.com: compile-cross-compiler
boot/toolchain.com:
        (echo '(begin' && \
         echo '  (with-working-directory-pathname "compiler"' && \
         echo '    (lambda () (load "make")))' && \
         echo '  (disk-save "boot/toolchain.com"))') \
        | '$(MIT_SCHEME_EXE)' --batch-mode --band runtime.com

The target Makefile would have rules like:

boot/toolchain.com:
        @echo 'You need to run `make -f Makefile.boot\'' first!' && exit 1

BOOTSTRAP_TOOLCHAIN = \
  '$(MIT_SCHEME_EXE)' --band ./boot/toolchain.com --batch-mode

.PHONY: compile-runtime
compile-runtime: boot/toolchain.com
compile-runtime: syntax-runtime
compile-runtime:
        (echo '(with-working-directory-pathname "runtime"' && \
         echo '  (lambda () (load "runtime.cbf")))') \
        | $(BOOTSTRAP_TOOLCHAIN)

This could be done right now, without any cross-compilation changes in
the code like you mentioned under `Scheme48ish Cross Compilation', to
fix the bug with star-parser, actually.  (The up-to-date star-parser
would get included in toolchain.com, as a provisional measure until we
fix the macro system.)  I might even find time this afternoon to throw
together a prototype.

   I would work on a cross-fasdumper, but I will need some really cool
   heap format changes to motivate me... "really cool" like eliminating
   SEQUENCE-3.

I wrote one back in June.  Can't remember whether I published it, but
I just uploaded it to

http://mumble.net/~campbell/tmp/mit-fasdump.scm

I don't seem to have any automatic tests for it, and it won't handle
compiled code, but it works and it's a start.

What it should do for compiled code is basically what crsend.scm does,
but with machine-independent I/O instead of doing machine-dependent
(object-set-type (ucode-type COMPILED-ENTRY) ...) and fasdumping that.

   LIAR/C and separate compilation can stay limited, bootstrapping
   techniques.  I drool for a modern luser's "just load it" build
   abstraction where compilation is just part of loading/evaluating.
   Autoloading pre-compiled "options" is so... last millenium.

I would like to be able to run a program without a macro expander,
compiler, &c., in the address space, and I would like all the code we
distribute to have been run through the macro expander and a static
analyzer (which for the moment is just sf and liar).  Fixing the
system so that loading without compiling and loading after compiling
have the same semantics is worthwhile; eliminating support for a
distinct compilation step altogether is not.

   If there is any objection to moving the star-parser into runtime/, now
   is the time to stop me. :-)

We ought to be moving stuff *out* of runtime/, not into it.  There's
already too much crap there.  Only stuff that is an important part of
a running Scheme program should go in there, really.

If something about the build system has the consequence that putting
star-parser/ into runtime/ is the only way to compile runtime/ with an
up-to-date star-parser/, then we ought to fix whatever it is about the
build system causes that.

                               And if there is any pressing need for a
   working make-native.sh, now is the time to ask.

If by `a working make-native.sh' you mean `a working way to build a
native system given a liarc system', then yes, I think there is a need
for that, unless everything above (which, as I said, I have not yet
read fully) supports cross-compilation already.  make-native.sh is
exactly how I brought up MIT Scheme on amd64 in the first place.