GitLab

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.

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 fixes the "does unsetenv return void" test in the unix package on
OS X, if I tell it to make 10.4-compatible binaries. The test uses
CPPFLAGS but not CFLAGS, so it thought it returned int (as it was
in 10.5-mode), but the C compiler (using CFLAGS, so in 10.4 mode)
thought it returned void.

I also added CONF_LD_OPTS_STAGE$3 to the list of things in LDFLAGS,
which looks like an accidental ommission.

I don't remember why we made it use gcc instead, but going back to
using ghc doesn't seem to break anything, and should fix the build
on OS X 10.6.

If the GHCi .o lib doesn't exist, load the .a instead

We weren't ignoring comment lines

And set hp2ps's EXTRA_LIBRARIES. Based on a patch from Sergei Trofimovich.

Instead of the ghc-stage and ghc-stage2-package files in a package, we
now have a list of these in ghc.mk.  There are other similar lists (of
boot-packages and non-installable packages), so this is not too bad,
and is simpler.

While poking around in the top-level ghc.mk file I spotted various
opportunities to clean up and re-order some of the cruft that has
accumulated over time.

saying

  make TRACE=1

prints most of the macro calls and their arguments.  It's easy to
trace new macros; see rules/trace.mk.

Also add some comments about what extra-packages is doing

rather than being repeated in the build system

Stops user-installed packages breaking the build

Rather than it having its own specialised version

I encountered a couple of things that broke after Ian's previous
patch: one was my nightly build scripts that use 'make stage=2' at the
top level, and the other is 'make fast' in libraries/base, which uses
'stage=0' to avoid building any compilers.

So my version of this patch is more direct: it just turns off the
appropriate dependencies using a variable set by 'make 1', 'make 2',
etc.

When we ask make to run "a | b", if a fails then the pipeline might
still exit successfuly.

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.