GitLab

Fixes #7780.

In particular, this means that GHCi will use DLLs, rather than loading
object files itself.

We now put a handful of modules in a separate DLL.
For now the list is hand-written, but we could automate it in the
future.

and use them for split

This makes the build system a little simpler, and in particular
will make it easier to handle the changes needed for cross-compilation.

This removes the '.PHONY' rule, so means that "make" in a built tree
won't repeat the check.

We also now check the .cabal files for the executables as well as the
libraries.

We have two cases:
 1. building a cross-compiler
 2. compiling GHC to run on a foreign platform

These two are done with almost the same setup: (1) is the stage 1
compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.

The only difference between (1) and (2) is that you if you set up the
build for (1), then it stops before stage 2 and you can 'make install'
to install stage 1.

Unfortunately, (2) didn't work, and the build system code needed some
tidying up.

Change to the way the build is set up:

Before
------

To build a cross-compiler:
  ./configure --target=<..>

To compile a foreign GHC:
  ./configure --host=<..> --target=<..>

Now
---

To build a cross-compiler:
  ./configure --target=<..>
  And set "Stage1Only=YES" in mk/build.mk

To compile a foreign GHC:
  ./configure --target=<..>

We want to compile the sources only once, and to produce both vanilla
and dyn object files. This means that the sources can't differ for the
two ways.

This needed a bit of a kludge to get keepCAFsForGHCi included only in
the dynamic library.

DeriveConstants.hs works in a cross-compilation-friendly way. Rather
than running a C program that prints out the constants, we just compile
a C file which has the constants are encoded in symbol sizes. We then
parse the output of 'nm' to find out what the constants are.

Based on work by Gabor Greif <ggreif@gmail.com>.

gcc couldn't find ghc_boot_platform.h. I'm not sure why it worked on
Linux.

We shouldn't be generating files in the source directories

We now also generate nice wrappers for the platformConstants
methods. For now it's all commented out as the definitions
conflict with those in Constants.

We now generate a platformConstants file that we can read at runtime.

To explicitly choose whether you want an unregisterised build you now
need to use the "--enable-unregisterised"/"--disable-unregisterised"
configure flags.

Related to #4862

They were getting baked into Config.hs before.

We also don't build DLLs for the dph-lifted-* packages as they depend
on ghc.

Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>

This is working towards being able to put ghcautoconf.h and
ghcplatform.h in includes/dist