Improve build reporting for cabal-install

Describe "cpp-option" field

Conflicts:
	cabal-install/Distribution/Client/Install.hs

Support multiple instances of package ID in database with different deps

detailed-1.0 test libraries allow users to define a test library as part
of package, which has a different package ID than the original library.
When I made the change to packageKey, I forgot to assign new package keys
here; the result was that the test library was compiled with the same
package key as the original.  The fix is a bit of a hack, since arguably
this should have been done properly in the configure step!

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

Duncan requested that cabal-install not try to put multiple entries in the
package database with duplicate package IDs (foo-0.1) until other tools (in
particular GHC) are able to deal with situation in a better way.  We want to
revert this commit soon, since with this turned on, we basically don't get any
benefit from the package key refactoring (no deliverance from Cabal hell.)

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

At the moment, $pkgkey is not supported for build reports, although in
principle we could add support for it, assuming that the configure step
succeeds.

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

Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
would only be one instance of it in the installed packages database.  This
posed problems for situations where you want a package compiled twice against
different sets of dependencies: they could not both exist in the package
database.

Package keys are a hash of the package ID and package
dependencies, which identify a package more uniquely than a package ID, but less
uniquely than an installed package ID. Unlike installed package IDs, these can
be computed immediately after dependency resolution, rather than after
compilation.  Package keys require support from the compiler.  At the moment,
only GHC 7.10 supports package keys (the reason is that old versions of GHC
do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
package database matches with the -package-name embedded in an hi file; so
the format is fixed.) We fallback to package keys == package IDs for old
versions.

Note: the ./Setup configure fallback script does not try particularly hard to
pick consistent sets of dependencies.  If your package database is too difficult
for it to resolve, manually provide installed package IDs or use cabal-install's
dependency solver.

Note: This patch *suspends* the reinstall check unless it would result in
a different package, so cabal-install will now happily reinstall foo-0.1
compiled against bar-0.2 if foo-0.1 already exists.

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

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

fix `sdist' tar invocation to be compatible with Solaris' tar

See #2023.

Now packages specified by directory or URL work with the --build-summary
option.

Fix build in the face of Applicative-Monad

Since 'empty' will now be exported by Control.Monad, this is needed to
disambiguate the 'empty' identifier from the one in Text.PrettyPrint.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Ask source directory in cabal init

Fixes #2009.

Makes it more clear what is going on.

Fixes #1715.

Fixes #1337.

This reverts commit 03c134d5.

Committed by mistake.

A few documentation fixes

While reading the docs, I saw a few typos, so I ran ispell through the
docs. Fixed:

- plain typos
- a few instances of 'ie'→'i.e.' and 'eg' → 'e.g.' for nicer style
- a few capitalisation issues (linux, unix)
- a few not-nice (IMHO) abbreviations (for a manual, that is):
  distro→distribution, repo→repository
- proper naming (RedHat→Red Hat)

Fixes #2016.

nkaretnikov authored Jul 26, 2014 and Mikhail Glushenkov committed Jul 26, 2014

Fixes #1962.

It looks like #1443 was actually fixed by the change from getModificationTime to
getModTime (which has higher resolution). The change to '>=' was not needed
because the code uses 'when', not 'unless'.

Thanks to Nikita Karetnikov for the heads-up.

Implement "reexported-modules" field, towards fixing GHC bug #8407. (ROUND 2)

D.Compat.CreatePipe: use locale encoding

Issue #1895. `createPipe` opened handles in binary mode by default,
which mangles text encoded for the current locale. Now, `hSetEncoding`
is called on the new handles. This requires `base >= 4.2`.

Read installed package info file as UTF-8