From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Removing compilers that cannot be bootstrapped Date: Tue, 22 Mar 2016 17:22:22 +0100 Message-ID: <87k2kutrcx.fsf@gnu.org> References: <87twjz4fcn.fsf@gnu.org> <98e61e40cf3c9fa4c9cf8bac578d5c37@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiP4n-0006f0-83 for guix-devel@gnu.org; Tue, 22 Mar 2016 12:22:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiP4h-00016L-Io for guix-devel@gnu.org; Tue, 22 Mar 2016 12:22:37 -0400 In-Reply-To: <98e61e40cf3c9fa4c9cf8bac578d5c37@openmailbox.org> (Eric Bavier's message of "Tue, 22 Mar 2016 09:57:28 -0500") 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: Eric Bavier Cc: guix-devel , guix-devel-bounces+ericbavier=openmailbox.org@gnu.org Eric Bavier skribis: > On 2016-03-21 17:48, ludo@gnu.org wrote: >> taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") skrib= is: >> >>> 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=E2=80=99d be possible to find, say, an old-enough GHC t= hat >> 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=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 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=E2=80=99.