guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing compilers that cannot be bootstrapped


From: Eric Bavier
Subject: Re: Removing compilers that cannot be bootstrapped
Date: Tue, 22 Mar 2016 09:57:28 -0500
User-agent: Roundcube Webmail/1.0.6

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.

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

--
`~Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]