Re: bootstrap integration strategies

[Ludovic Courtès]

Hello OriansJ,

"Orians, Jeremiah (DTMB)" <address@hidden> skribis:

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

Sounds nice.  I wonder if Jan was referring to something else then?

There’s still the question of GNU/Hurd, though, which requires a vastly
different libc.

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

So far the initial ports of Guix to non-x86 were done through
cross-compilation (info "(guix) Porting").  So in a way, the binary
seeds for these platforms were built from source; we just “cut” the
source-to-binary connection by making those binaries the root of the
dependency graph on these platforms.

Maybe that’s something we’ll have to live with on new architectures.

>> 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, problem solved?  Or am I missing something? :-)

I think the ‘wip-bootstrap’ branch does not use M1 at this point, does
it?

[...]

>> 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 ;-)

I wonder what it would take to fix that.  After all, compiling libguile
must not be much harder than compiling tcc, no?

> 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

One thing at a time.  :-)

IMO what matters most at this point is to come up with a plan that allow
us to incrementally reduce the size of our binary seeds.  A port of
M1/stage0 to Z80 can wait.  ;-)  So we really need a list of actionable
items in the short term to start taking advantage of all the work that’s
been done on Mes, MesCC, M1, stage0, Gash, etc.

Thanks for your feedback!

Ludo’.