GHC generics are used to derive binary instances for types appearing
in the persistent build config, which requires GHC >= 7.2 and
binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
The missing module is Data.Binary.Generics, which we have copied from
binary-0.7.2.3 to Distribution.Compat.Binary.Generics. To provide
generic implementations for the Binary class, we also have to provide
our own implementation, which is copied from binary-0.7.2.3 to
Distribution.Compat.Binary.Class. The interface required by Cabal is
exported from Distribution.Compat.Binary. This is only done if
bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
otherwise Distribution.Compat.Binary simply re-exports Data.Binary.

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

Fixes #2321.

Register GHC 7.10 extensions.

Fixes #2291.

We map all --enable-debug-info=n to -g in GHC.

If the compiler (e.g. GHC 7.10) supports outputting OS native debug
info (e.g. DWARF) passing --enable-debug-info[=n] to cabal will
instruct it to do so.

We need to know which version of network we installed.

Hopefully fixes #2310 for real.

Fixes #2310.

That package doesn't have any modules and Hadddock chokes.

Fix typo

Fixes #2241.

I think the ProgramDB API should be redesigned to prevent such
problems in the future.

bootstrap.sh: adapt to Cabal 1.22 version bump

for the windows clean hack.

This would cause exceptions when using a cached setup executable,
making parallel builds on Windows completely unusable.

for the windows clean hack.

This would cause exceptions when using a cached setup executable,
making parallel builds on Windows completely unusable.

generate CURRENT_PACKAGE_KEY macro in `cabal_macros.h`

Now that Cabal is in charge of RPATH handling on certain OS',
we must always setup a correct (DY)LD_LIBRARY_PATH when
running the testsuite. Not just when we are building relocatable
packages.

The "problem" is, is that Cabal now adds an RPATH pointing
to the installation location of the library. However, during
testing, the library won't be there yet. We much hence setup
a (DY)LD_LIBRARY_PATH that includes the dist/build dir.

Fix compilation ways