tech-pkg archive

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

Updating plans of lang/ghc


I'm the one who has maintained wip/ghc, and I became a NetBSD
developer just recently.

There are currently two competing plans for updating lang/ghc, namely
lang/ghc-bootstrap and lang/ghc7. I think there are pros and cons for
these plans but let me first clarify the starting point of wip/ghc
bootstrap kits, which support the following 5 platforms:

* NetBSD/i386, FreeBSD/i386, Darwin/ppc: The kits for these platforms
  derived from the old GHC where bootstrapping only with a C compiler
  via C bootstrap kit was possible. I originally started wip/ghc with
  these 3 platforms requiring no binary blobs. Since the vast majority
  of GHC developers solely uses either Linux/amd64 or Darwin/amd64, it
  tends to break on other platforms so I had to fix GHC myself and
  send patches to the upstream each time it breaks.

* NetBSD/amd64: There were no working GHC on the planet for this one
  so I had to wait for it to support cross-compilation (regardless of
  how many people asking me to get wip/ghc available for this
  one). After that I cross-compiled GHC for NetBSD/amd64 using wip/ghc
  on FreeBSD/i386 with lots of tinkering and fiddling. GHC stopped
  supporting C bootstrap kits in exchange for supporting
  cross-compilation, i.e. producing native code directly for a foreign
  platform with the help of cross-compiling GCC and Binutils.

* Linux/amd64: The official GHC binary for this one, distributed by, only works on fairly recent versions of Linux. Since I
  didn't have a Linux box that was recent enough to run it, I again
  cross-compiled GHC for this platform using wip/ghc on
  NetBSD/amd64. This time it wasn't as painful as for NetBSD/amd64
  because most of the cross-compilation issues were already fixed
  either by me or some other GHC developers.


I like the idea of lang/ghc-bootstrap. It is fairly attractive to have
a bootstrap kit installed as an usual pkgsrc package. The one thing I
am concerning about is that users will have to find and install a
binary package if they want to build lang/ghc themselves, otherwise
they'll end up standing in front of a circular
dependency. pkg_rolling-replace might complain about it each time the
packages get updated, even if both lang/ghc-bootstrap and lang/ghc
(somewhat old ones) are installed. I'm not sure this is OK or not. On
the other hand lang/ghc7 (and wip/ghc) are free from this problem, but
their bootstrap kits are somewhat inelegant.

Stepwise upgrade from 6.8.3 is a pain as I presented above. Each
version of GHC has different issues on different platforms. Assuming
wip/ghc bootstrap kits are now clean enough to start with, we could
make use of wip/ghc to jump to 7.6.2 for the above 5 platforms. I mean
lang/ghc-bootstrap could start from 7.6.2. But how about ones that
were covered by lang/ghc but not by wip/ghc, namely Darwin/i386,
OpenBSD/i386 and SunOS/i386? Can anyone do the stepwise upgrade or
cross-compilation of 7.6.x for them? If not, is it OK for us to drop
support for these ones?

Any thoughts?

 - PHO -               
OpenPGP public key: 1024D/1A86EF72
Fpr: 5F3E 5B5F 535C CE27 8254  4D1A 14E7 9CA7 1A86 EF72

Attachment: pgptMjSPozrAC.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index