GitLab

Note that some things depending on the rts/includes header files now
depend on more files: They used to include depend on includes/*.h, but
now they also depend on header files in subdirectories. As far as I can
see this was a bug.

Avoids repeated evaluations of things that need system calls etc

From
    http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/PhaseOrdering

Phase 0:
    Includes: package-data.mk files for things built by the
              bootstrapping compiler.
    Builds:   the dependency files for hsc2hs and genprimopcode. We need
              to do this now, as hsc2hs needs to be buildable in phase 1's
              includes (so that we can make the hpc library's .hs source
              files, which in turn is necessary for making its dependency
              files), and genprimopcode needs to be buildable in phase 1's
              includes (so that we can make the primop-*.hs-incl files,
              which are sources for the stage1 compiler library, and thus
              necessary for making its dependency files).
Phase 1:
    Includes: dependency files for things built by the bootstrapping
              compiler.
    Builds:   package-data.mk files for everything else. Note that this
              requires configuring the packages, which means telling cabal
              which ghc to use, and thus the stage1 compiler gets built
              during this phase. 
Phase "":
    Includes: dependency files for everything else.
    Builds:   Everything else. 

For some reason the Windows HEAD builder has started thinking the ghci
flag should be on in stage 1. This should fix it, and generally make
things a little more resilient.

Now that we used cabal to configure the ghc-bin package they are no
longer needed.

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.

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.