From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Bavier Subject: Re: Removing compilers that cannot be bootstrapped Date: Tue, 22 Mar 2016 09:57:28 -0500 Message-ID: <98e61e40cf3c9fa4c9cf8bac578d5c37@openmailbox.org> References: <87twjz4fcn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiNks-00073Y-Dj for guix-devel@gnu.org; Tue, 22 Mar 2016 10:57:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiNkl-0001n0-Es for guix-devel@gnu.org; Tue, 22 Mar 2016 10:57:55 -0400 In-Reply-To: <87twjz4fcn.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: ludo@gnu.org Cc: guix-devel , guix-devel-bounces+ericbavier=openmailbox.org@gnu.org On 2016-03-21 17:48, ludo@gnu.org wrote: > taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") skri= bis: >=20 >> A while back Mark raised the idea of hosting one pre-compiled=20 >> bootstrap >> version of each such compiler, and use that to compile further=20 >> versions. >>=20 >> This way the number of blobs is one per such compiler, instead of one >> for every new version of each such compiler. >>=20 >> It seemed like a good medium-term solution to me. I'm not sure how it >> would be implemented. >=20 > I like the idea. >=20 > Often, in their implementation history, compilers are boostrapped from > something else initially, and only later to they become self-hosted and > unbootstrappable. >=20 > So in theory, it=E2=80=99d be possible to find, say, an old-enough GHC = that=20 > only > requires a C compiler (?), and use that to build the next version and=20 > so > on, until we reach the latest version. I suspect the same applies to > many compilers. >=20 > This is technically possible. The main difficulty is to find what=20 > 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. >=20 > But really, we won=E2=80=99t know until we=E2=80=99ve actually tried ;-= ), and it=E2=80=99ll > be different for each compiler. My initial attempt at packaging GHC before our current package went this=20 route, ultimately to no avail. The earliest publicly-available GHC=20 source tarball is indeed "just C", but it is machine-generated C code=20 much like Chicken Scheme's. Some software archeology might be able to produce a still earlier=20 version of GHC from a developers private collection. --=20 `~Eric