Re: Removing compilers that cannot be bootstrapped

[Eric Bavier <ericbavier@openmailbox.org>]

On 2016-03-21 17:48, ludo@gnu.org wrote:
> taylanbayirli@gmail.com (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.

Some software archeology might be able to produce a still earlier 
version of GHC from a developers private collection.

-- 
`~Eric