Re: Updating plans of lang/ghc

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Wed, Jan 08, 2014 at 11:05:16AM +0200, Alan Barrett wrote:
 > >The idea is that ghc-bootstrap depends on ghc (used for building) but
 > >ghc does *not* depend on ghc-bootstrap; instead once in a while
 > >someone takes the ghc-bootstrap package from the build host and posts
 > >it as a distfile in MASTER_SITE_LOCAL, and updates the distfile
 > >information in the main ghc package. I think this avoids most of the
 > >problems that otherwise come up.
 > 
 > Let's see if I understand this idea.
 > 
 > When you build ghc from pkgsrc, it downloads a binary blob from
 > MASTER_SITE_LOCAL, and uses that as a compiler to build the current
 > version of ghc from source code written in Haskell.
 > 
 > That binary blob is the result from somebody building ghc-bootstrap
 > some time in the past, which then depended on ghc (possibly an
 > older version), which depended on an older version of the binary
 > blob.
 > 
 > That older version of the binary blob depends (indirectly) on an
 > even older version of the binary blob, etc.  The number of steps in
 > the chain are limited by uploading new versions of the binary blob
 > as seldom as possible (essentially, only when the old bootstrap
 > blob is not good enough to build a new compiler).

Yes.

 > How was the very first version of the binary blob in
 > MASTER_SITE_LOCAL built?  Is there a history traceable to a version
 > that depended only on C code and a C compiler?

The current bootstrap kit for the current lang/ghc package is
compiler-generated C code. That could be taken as a starting point,
although compiler-generated C code isn't much better than a binary
blob.

I'm not sure where it came from per se; kristerw made it a long time
ago. (I believe at one point it used to be possible to download the
bootstrap C files from upstream, although I think that ended before
the version currently in pkgsrc.)

 > Will all the binary blobs, and the sources from which they were
 > built, be saved ~forever, in case somebody wants to audit the
 > provenance chain in the future?

Ideally they should be, yes. So I guess they should probably be kept
somewhere more specific than MASTER_SITE_LOCAL to make sure they don't
accidentally get cleaned out in the future.

 > Can ghc be built using some other Haskell implementation?

Not AFAIK. But even if it theoretically can, the others (hugs and
nhc98) don't really work well enough to do this in practice. I updated
nhc98 recently, but it still supports 64-bit platforms only by
compiling itself with -m32. Also it won't run on one of my machines
for some reason I haven't got around to chasing down.

-- 
David A. Holland
dholland%netbsd.org@localhost