GitLab

As far as I can see this has been wrong for some time, but only bit
recently.

This means we get -XHaskell98 added to the list of flags, just like we
would if we were building with Cabal.

I expect this will fix:
http://www.haskell.org/pipermail/cvs-ghc/2011-January/059098.html

The standard libraries/$depname scheme doesn't apply, so we need to
handle it specially.

There are problems with dtrace on 64bit 10.5. For now at least, we
just turn dtrace off unless you override USE_DTRACE

and they accept different flags, so for now do nothing

now that cross-package deps are tracked correctly.

In particular, this means ghc gets built with -rtsopt, -threaded, etc again.

We can now rely on cross-package deps working properly, as we require
GHC 6.12.

We no longer use dummy-ghc; instead we don't configure most packages
until the stage1 compiler is available.
  
We also now use Cabal for building the ghc-bin package.

There are a couple more sanity checks too.

Fixes a rare race when both libHSffi.a and libHSffi_p.a were being built
at the same time:

"cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a
"cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a
"cp" libffi/dist-install/build/libffi.so libffi/dist-install/build/libHSffi-ghc7.1.20110115.so
cp: cannot create regular file `libffi/dist-install/build/libHSffi.a': File exists

Johan discovered that when INLINABLE things are specialised
bad things can happen. This patch implements a hack -- but
it's a simple hack and it solves the problem.

See Note [Inline specialisations]. 

The hack part is that really INLINABLE should not cause *any* loss
optimisation, and it does; see Note [Don't w/w INLINABLE things] in
WorkWrap.

Under obscure circumstances (actually only shown up when fixing something
else) it was possible for a variable binding to be discarded although
it was still used.  See Note [Top level and postInlineUnconditionally]