Eric Bavier <ericbav...@openmailbox.org> skribis: > On 2016-03-21 17:48, l...@gnu.org wrote: >> taylanbayi...@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.
Oh, good to hear that you tried and failed. It sounds like GHC bootstrapping will be very hard to address. Ludo’.
