GitLab

Installing and bindist creation don't work, but they were already broken.
Only tested validating with one setup.

This fixes trac #2266.

Compat.Unicode is not utils/Unicode in the compiler.
We build the hpc package with the stage1 compiler.
Nothing else in the compat package was still used.

Now we just run make in it at the start of the stage1 build

We now build a copy of Cabal and put it in a bootstrapping package.conf.

We also make boot in libraries much earlier in the build process, so we
can use cabal-bin for more stuff in the future.

It leads to annoying rebuilding when working in a built tree.
We'll handle this differently for 6.10.

This replaces the hand-rolled architecture-specific FFI support in
GHCi with the standard libffi as used in GCJ, Python and other
projects.  I've bundled the complete libffi-3.0.4 tarball in the
source tree in the same way as we do for GMP, the difference being
that we always build and install our own libffi regardless of whether
there's one on the system (it's small, and we don't want
dependency/versioning headaches).

In particular this means that unregisterised builds will now have a
fully working GHCi including FFI out of the box, provided libffi
supports the platform.

There is also code in the RTS to use libffi in place of
rts/Adjustor.c, but it is currently not enabled if we already have
support in Adjustor.c for the current platform.  We need to assess the
performance impact before using libffi here too (in GHCi we don't care
too much about performance).

- GHC installs a range of compiled Haskell programs in addition to the actual
  compiler.  To ensure that they all run on the platform targeted by the build
  (which may have different libraries installed than the build host), we need
  to make sure that all compiled Haskell code going into an install is build
  with the stage 1 compiler, not the bootstrap compiler.  Getting this right
  is especially important on the Mac to enable builds that work on Mac OS X
  versions that are older than the one performing the build.
- For all installed utils implemented in Haskell (i.e., ghc-pkg, hasktags,
  hsc2hs, runghc, hpc, and pwd) we compile two versions, an inplace version
  and a version for installation.  The former is build by the bootstrap
  compiler during the stage 1 build and the latter is build by the stage 1
  compiler during the stage 2 build.
- This is really very much as the setup for ghc itself, only that we don't use
  separate stage1/ and stage2/ build directories.  Instead, we clean before
  each build.  CAVEAT: This only works properly if invoked from the 
  toplevel Makefile.
- Instead of UseStage1=YES (as used by the previous binary-dist-specific
  recompilation), we now use the same $(stage) variables as used for the
  compiler proper - to increase uniformity and to avoid extra conditionals for
  the install target.

- Also moving all MacOS-specific Makefile components into 
  distrib/MacOS/Makefile

- GHC as a Mac framework
- I tried to make a package where the user could choose whether to install
  in /Library/Frameworks or ~/Library/Frameworks (to allow installation for
  non-admins).  However, that doesn't work well without including the whole
  distribution twice as the decision as to whether the admin password needs
  to be entered is made at packaging time (not at install time).

- Ensure the stage1 compiler uses ghc's own GMP library on Mac OS
- Need to rebuild installPackage and ifBuildable with stage1 compiler as they
  go into bindists

This is a bit unpleasant, as "make binary-dist" really shouldn't actually
build anything, but it works.

If Cabal doesn't see the .ly file then it won't try to run happy, and
thus won't fail if happy isn't installed.

This is a hack, but it means we get libHSrts*.a etc rather than just
libHSrts.a.

The previous hack to include Parser.hs in source distros broke the possibility
of doing a "make dist" in a fresh tree, i.e. one which has just been checked
out and configured, but *not* built. Of course you will need Happy for such a
source distro later, but at least the freedom to do this is important.

The ultimate goal should be that something like "make dist" will work in a
freshly checked out tree, with no prerequisite steps (this is very common in
most projects). We should move towards that goal, not away from it...


MERGE TO STABLE