Re: bootstrap integration strategies

["Orians, Jeremiah (DTMB)" <OriansJ@michigan.gov>]

> I think that's the main difficulty.  I think we'd rather not have
> separate bootstrap paths for Intel GNU/Linux on one hand, and everything
> else on the other hand.

Well, due to the design of mescc-tools; the bootstrap paths only have to be divergent up to the M1-macro level.
After that, we could simply use flags make the source work on different platforms

> Yet, we know that porting what you already did on x86-linux-gnu to
> GNU/Hurd and ARMv7 and AArch64 etc. is going to be a lot of non-trivial
> work (especially since historical versions of the GNU toolchain did not
> support AArch64, for instance.)
Nor RISC-V but that is likely to be a much bigger issue in terms of bootstrapping

> Waiting for this to be "solved" (and we don't even know how) would
> equate to a status quo.  But obviously, it'd be sad to have all this
> work already done on Intel and not be able to benefit from it.
Actually the work for the stage0 bootstrap steps have already been done on non-x86 hardware (Knight platform to be precise)
And the engineering decisions involved where explicitly selected to minimize porting and cross-platform bootstrapping effort.
M1-macro and hex2-linker only need flags to be set to build for all of the different supported platforms

> So perhaps we'll have to get over it and have a different bootstrap path
> on x86-linux-gnu.
A multiway bootstrap path that exceeds the requirements of DDC actually

> (BTW, I suspect we can get away with using 32-bit bootstrap binaries on
> both i686/x86_64 and armv7/aarch64, no?)
For AMD64, absolutely, ARM however I am not familiar enough to say

> Gash seems to be a low-hanging fruit and a relatively easy thing,
> because it's architecture-independent.  How
> far is it from being able to run typical 'configure' scripts?
Well we would have to replace the parser at a bare minimum

> I think the day it's able to run 'configure' scripts, we can switch to
> it right away without further ado, and then incrementally improve it as
> we stumble upon limitations and bugs.
Well we only need Gash to get to the build make and bash level, after that its scope can be limited.
In theory, someone could hand replace the make build script with a custom version that gash can use right now instead of us enhancing gash

> There's also another option you didn't mention: ditching the 2.0
> bootstrap Guile in favor of Mes.  That can be done in several steps:

>  1. Replace the guile-2.0.*.xz binary tarballs with Mes, and add a step
>      that builds Guile 2.x using our big bootstrap GCC binary.
Slow but possible

>   2. Same, but build Guile 2.x, libgc, etc. using MesCC.
MesCC can't directly build Guile yet but I do enjoy that ambition ;-)

> This could allow us to remove quite a lot of MiBs from our binary seeds.
FTFY

At this point, we effectively have a rope bridge to full bootstrappability
But we still have a lot of details to hammer out, like getting basic ARM support and having the ARM and x86 binaries verify each other's bootstrap;
Finding 6502, z80, 8051, 68K, VAX, pdp11, Alpha, MIPS, SPARC and PowerPC/Power Developer(s) to do stage0 work for their platforms and perform the cross verify steps.
Hammer out cross-platform build details for MesCC and M2-Planet

Jeremiah Orians
Cell phone: (517) 896-2948