It has been deprecated for long and already removed from ghc --help

It's been deprecated for who knows how long, and gives a warning.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

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

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.

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.

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

We now define _PROGNAME, and _PROG is automatically defined with
$(exeext). This will shortly automatically use the right exeext
depending on what stage it is being compiled with (exeext may be
different for different stages when cross-compiling).

and use them for split

It doesn't seem to do anything that _INSTALL and _INSTALL_INPLACE
can't do.

Thanks to Daniel Pratt <colorblinddad@gmail.com> for pointing out the failure
and fix.

Caught by -Werror

We use the in-place windres, which isn't guaranteed to work with the
stage0 compiler.

hppa1, m68k

We avoid calling "rm -rf" with no file arguments; this fixes cleaning
on Solaris, where that fails.

We also check for suspicious arguments: anything containing "..",
starting "/", or containing a "*" (you need to call $(wildcard ...)
yourself now if you really want globbing). This should make things
a little safer.

cygwin's /bin/install doesn't set file modes correctly if the
destination path is a C: style path:

$ /bin/install -c -m 644 foo /cygdrive/c/cygwin/home/ian/foo2
$ /bin/install -c -m 644 foo c:/cygwin/home/ian/foo3
$ ls -l foo*
-rw-r--r-- 1 ian None 0 2011-01-06 18:28 foo
-rw-r--r-- 1 ian None 0 2011-01-06 18:29 foo2
-rwxrwxrwx 1 ian None 0 2011-01-06 18:29 foo3

This causes problems for bindisttest/checkBinaries.sh which then
thinks that e.g. the userguide HTML files are binaries.

We therefore use a /cygdrive path if we are on cygwin

This was done as part of an honours thesis at UNSW, the paper describing the
work and results can be found at:

http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf

A Homepage for the backend can be found at:

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM

Quick summary of performance is that for the 'nofib' benchmark suite, runtimes
are within 5% slower than the NCG and generally better than the C code
generator.  For some code though, such as the DPH projects benchmark, the LLVM
code generator outperforms the NCG and C code generator by about a 25%
reduction in run times.

We now regenerate them when installing, which means the path for perl
doesn't get baked in