[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] A tale of four builds.
Date: Fri, 4 Oct 2013 13:41:41 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99

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

   I don't know about converting to a set of
   parallelizable makefile rules.  The need for makes it... not
   obvious to me.  My only example is the pair of scripts and

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/
        # Get the bootstrap objects out of the way.  (This is a little
        # sleazy.  Could save them with, alternatively, or do
        # this outside of make.)
        $(MAKE) clean

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

The target Makefile would have rules like:

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

  '$(MIT_SCHEME_EXE)' --band ./boot/ --batch-mode

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

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, 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

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

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, now is the time to ask.

If by `a working' 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. is
exactly how I brought up MIT Scheme on amd64 in the first place.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]