Re: Removing compilers that cannot be bootstrapped

[Ludovic Courtès]

Eric Bavier <address@hidden> skribis:

> On 2016-03-21 17:48, address@hidden wrote:
>> address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:
>>
>>> A while back Mark raised the idea of hosting one pre-compiled
>>> bootstrap
>>> version of each such compiler, and use that to compile further
>>> versions.
>>>
>>> This way the number of blobs is one per such compiler, instead of one
>>> for every new version of each such compiler.
>>>
>>> It seemed like a good medium-term solution to me.  I'm not sure how it
>>> would be implemented.
>>
>> I like the idea.
>>
>> Often, in their implementation history, compilers are boostrapped from
>> something else initially, and only later to they become self-hosted and
>> unbootstrappable.
>>
>> So in theory, it’d be possible to find, say, an old-enough GHC that
>> only
>> requires a C compiler (?), and use that to build the next version
>> and so
>> on, until we reach the latest version.  I suspect the same applies to
>> many compilers.
>>
>> This is technically possible.  The main difficulty is to find what
>> exact
>> chain of compiler versions will work, and then to make sure that the
>> super-old compilers can build.  The risk, as Andreas suggests, is that
>> maintaining those old versions will require dragging a whole graph of
>> old dependencies, recursively.
>>
>> But really, we won’t know until we’ve actually tried ;-), and it’ll
>> be different for each compiler.
>
> My initial attempt at packaging GHC before our current package went
> this route, ultimately to no avail.  The earliest publicly-available
> GHC source tarball is indeed "just C", but it is machine-generated C
> code much like Chicken Scheme's.

Oh, good to hear that you tried and failed.

It sounds like GHC bootstrapping will be very hard to address.

Ludo’.