GitLab

Based on a patch from David Terei.

Some parts are a little ugly (e.g. defining things that only ASSERTs
use only when DEBUG is defined), so we might want to tweak things a
little.

I've also turned off -Werror for didn't-inline warnings, as we now
get a few such warnings.

We were getting
    InstallExtraPackages="YES    "

Rather than using the compiler that configure detects, we use
the "GCC command" field from the --info output of the bootstrapping
compiler (provided it is >= 7.1).

This allows different gcc's to be used when building different stages,
which we need to do when cross-compiling.

It couldn't be overridden, and was defined as YES.

Previously the code generator generated small code fragments labelled
with __stginit_M for each module M, and these performed whatever
initialisation was necessary for that module and recursively invoked
the initialisation functions for imported modules.  This appraoch had
drawbacks:

 - FFI users had to call hs_add_root() to ensure the correct
   initialisation routines were called.  This is a non-standard,
   and ugly, API.

 - unless we were using -split-objs, the __stginit dependencies would
   entail linking the whole transitive closure of modules imported,
   whether they were actually used or not.  In an extreme case (#4387,
   #4417), a module from GHC might be imported for use in Template
   Haskell or an annotation, and that would force the whole of GHC to
   be needlessly linked into the final executable.

So now instead we do our initialisation with C functions marked with
__attribute__((constructor)), which are automatically invoked at
program startup time (or DSO load-time).  The C initialisers are
emitted into the stub.c file.  This means that every time we compile
with -prof or -hpc, we now get a stub file, but thanks to #3687 that
is now invisible to the user.

There are some refactorings in the RTS (particularly for HPC) to
handle the fact that initialisers now get run earlier than they did
before.

The __stginit symbols are still generated, and the hs_add_root()
function still exists (but does nothing), for backwards compatibility.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

The .hsc files aren't currently safe for cross-compilation on Windows:
    libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:160
    directive "let" is not safe for cross-compilation

Patch from Brian Bloniarz

We used to have
    MK_INSTALL_DEST = "$(shell cygpath $1)"
but this meant we ended up with
    "$(shell cygpath "[...]/html/`basename $$i`")"
and the $(...) gets evaluated before the makefile rule, so the for loop
hasn't been run, and so $i isn't defined. So we were taking the basename
of the empty string, meaning docs weren't being installed in the right
place.

Now we have
    MK_INSTALL_DEST = $$(cygpath $1)
so the evaluation happens in the shell, while the for loop is running.

Now that we've stopped trying to support 64bit OS X 10.5, the DTrace
problems there don't matter.

This changes the new code generator to make use of the Hoopl package
for dataflow analysis.  Hoopl is a new boot package, and is maintained
in a separate upstream git repository (as usual, GHC has its own
lagging darcs mirror in http://darcs.haskell.org/packages/hoopl).

During this merge I squashed recent history into one patch.  I tried
to rebase, but the history had some internal conflicts of its own
which made rebase extremely confusing, so I gave up. The history I
squashed was:

  - Update new codegen to work with latest Hoopl
  - Add some notes on new code gen to cmm-notes
  - Enable Hoopl lag package.
  - Add SPJ note to cmm-notes
  - Improve GC calls on new code generator.

Work in this branch was done by:
   - Milan Straka <fox@ucw.cz>
   - John Dias <dias@cs.tufts.edu>
   - David Terei <davidterei@gmail.com>

Edward Z. Yang <ezyang@mit.edu> merged in further changes from GHC HEAD
and fixed a few bugs.

The logic is now in mk/compiler-ghc.mk rather than being duplicated in
ghc/Makefile and compiler/Makefile.

The use is in install.mk.in, where we need to know when
we're on Cygwin.

This fixes the build on my Windows box, where I have
both Msys and Cygwin.

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

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