Sorry for the long delay. Please do this at your discretion. I am not actively working on anything and will catch up when it's done.
On Mon, Jan 7, 2019 at 12:41 AM Taylor R Campbell <[email protected]> wrote: > > Date: Sun, 6 Jan 2019 04:31:00 +0000 > > From: Taylor R Campbell <[email protected]> > > > > > 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.) >
_______________________________________________ MIT-Scheme-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
