Date: Thu, 3 Oct 2013 13:55:36 -0700
From: Matt Birkholz <m...@birchwood-abbey.net>
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.
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
