Authored-by: Christiaan Baaj <christiaan.baaij@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This includes both executables (by correcly setting the rpath to the
topDir) and libffi, and GHC itself, so that everything works with no
build tree.

Authored-by: Christiaan Baaj <christiaan.baaij@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

On Windows, the ranlib in the path may not be the right ranlib (it may
be the 32bit ranlib when we are making a Win64 compiler, or vice-versa).
Therefore we can't leave it up to libffi to detect the right ranlib, but
need to tell it which ranlib to use. This means that we need to find
ranlib even if we don't actually need it ourselves.

Part of #7833

Make expands things even in comments

We need different paths in the wrapper, as teh installed tree is a
different shape to the build tree.

When GHCi makes temporary DLLs, those also need to be linked against
the right RTS, or we won't be able to load them.

This is particularly important as without it validate fails, as it
tries to pass RTS options to haddock, and with the default RTS config
those options aren't permitted.

There's now an internal -dll-split flag, which we use to tell GHC how
the GHC package is split into 2 separate DLLs. This is used by
Packages.isDllName to determine whether a call is within the same
DLL, or whether it is a call to another DLL.

It now consistently takes directory and distDirectory as its first 2
arguments. Also, it only supports configuring 1 package at a time now
(we weren't using the ability to configure more than one at once).

Dynamic GHC is now working in-place, but pathologically slow due
to the DLL split.

(GHC assumes that all intra-package calls are in the same DLL, but that
isn't true when we split the GHC package into 2 DLLs. That means that
GHC's startup time is around 22 seconds, as it is doing run-time
linking).

Also, ghci isn't actually working yet:

$ inplace/bin/ghc-stage2 --interactive
GHCi, version 7.7.20130512: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... <command line>: can't load .so/.DLL for:
HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL)
ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be
found.

Not just base, integer-gmp and ghc-prim.

Patch from pgj; part of #7819.

On FreeBSD, one needs use "-z origin" in order to enable resolution
of $ORIGIN in RPATH. Part of #7819.

Patch from Stephen Blackheath.

The ghc-stage1_INPLACE variable wasn't being defined

Currently they are all set to the same value, but when cross-compiling
they could be set to different values.

Also a couple of other fixes and sanity checks along the way.

We no longer pass -hisuf/-osuf flags to "ghc -M". Doing so didn't really
make sense with the way the -dep-suffix flags now work.

Spotted by Bill Tutt

other than Windows and OS X.

It's known to work on Linux and FreeBSD.

It thought that /all/ ways should create the dyn o/hi files, but only
the v way does.

In particular, this means that GHCi will use DLLs, rather than loading
object files itself.

We now put a handful of modules in a separate DLL.
For now the list is hand-written, but we could automate it in the
future.