Re: [MIT-Scheme-devel] Rework amd64 ABI -- flag day

[Taylor R Campbell]

> Date: Sun, 6 Jan 2019 04:31:00 +0000
> From: Taylor R Campbell <address@hidden>
> 
> > It sounds like this will break our rule about being able to build the next
> > release from the current one. Is that right? I don't object, but it will
> > have to eventually be explained at the time of release. Unless the
> > changeover can be scripted so that the rule isn't broken.
> 
> I'll see if I can find a convenient way to script this.

The easiest way I could find to do this was just to use a bootstrap
toolchain like I did before.  As before, it works by building a
syntaxer and compiler from the current tree that runs on the host
Scheme.  Usage model:

# On the host system with a host Scheme, say an amd64 system:
% ./Setup.sh
% ./configure --enable-cross-compiling --enable-native-code=i386
% make cross-host

# On the target system with no host Scheme:
% make all

What is different from how it worked before:

1. Build uses bootstrap toolchain only if --enable-cross-compiling.
2. Bootstrap toolchain can actually handle cross-compiling now.
3. All bootstrap toolchain objects, including intermediate .bins and
   .coms, live entirely under tools/.

Part (2) was made possible by the portable fasdumper from the
cross-fasdump-v2 branch, now merged into master, and requiring no
support by the host Scheme.

Part (3) is made possible by some new variables in SF and CREF
identifying roots of the source and object trees.  Taking advantage of
this to build the bootstrap toolchain requires support in the host
Scheme, so we can't build the bootstrap toolchain with 10.1, but the
build _without_ a bootstrap toolchain (the default) still works fine.

So, if we cut (say) 10.2 from master as it is now, then we can merge
riastradh-20181220-closentry-v3 (was v2, v3 is rebased on master as of
tonight) into 10.3 and we will be able to go 10.1 -> 10.2 -> 10.3 with
no trouble except that a 10.2 -> 10.3 build on amd64 will _require_
using --enable-cross-compiling.

How does that sound?


(Eventually I want to get rid of the separate `make cross-host' vs
`make all' steps by making everything cross-compilable by default, but
that requires us to have a little more formalism for getting macros
across subsystem boundaries than a compile.scm script that calls
load-option, and also requires us to have some kind of a static
cross-linker.)