GitLab

When building things to run in the build tree, we want the install name
to be the location in the build tree.

Bindists may be installed somewhere other than the configured install
location, so we weren't even necessarily setting it to the right value.

It doesn't really belong in package-data.mk

Unfortunately, dlsym finds the first symbol loaded, while when we reload
a compiled module in GHCi it's the last symbol that we want. Therefore
we remember the list of loaded DLLs ourselves and go through them in
order.

We instead link objects into a temporary DLL and dlopen that

We don't use them (we use the .so/.dll instead), so no point generating
them.

these can go into the release 7.6.2 too, I guess

We should be lazy when type-checking the equality-contraint
part of a data constructor's type, to make the knot-tying
work out right.  The fact that it's always worked before
is a fluke: no one else wrote a GADT whose type index mentions
itself
  data T a wher
    MkT :: T (T Int)

The issue here was with a function type written prefix
  (->) a b
where we were not generating a FunTy, which blew the
invariant that function types are always FunTys.  We
can't look at the TyCon directly because it may be
knot-tied, so we look at the name instead.

We used to say

    $ ghc-pkg list blargle
    /usr/local/lib/ghc-7.4.1/package.conf.d

which may imply that blargle was found in
/usr/local/lib/ghc-7.4.1/package.conf.d

gcc couldn't find ghc_boot_platform.h. I'm not sure why it worked on
Linux.

They are no longer used

We no longer produce installers fo OS X; we leave that to the Haskell
Platform team.

We shouldn't be generating files in the source directories

It used to be part-dynamic, part-static.