Helped extra-ghci-libraries find its way to .cabal files.
Change the inplace package database to not use file-style database.

Instead we use HcPkg.init (e.g. ghc-pkg init). For ghc-pkg this will
create a new directory style db.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Duncan Coutts <duncan@well-typed.com>
Switch InstallPlan over to using IPID-indexed PackageIndex.

While this doesn't let us get rid of Distribution.Client.PackageIndex,
it does make InstallPlan more flexible, so we can have the same
package name-package version in the install plan multiple times.
We do this by synthesizing fake installed package IDs to act
as placeholders prior to compilation.

There is some shindig with 'FakeMap' in PackageIndex, check out
the Note in that file for more details.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Add a comment to buildDepends saying not to use it.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Fixed links and anchors in Cabal user guide.
Merge pull request #2074 from rudymatela/master

Fixed links and anchors in Cabal user guide.
Merge pull request #2073 from ezyang/ezyang-build-depends-comment

Add a comment to buildDepends saying not to use it.
Merge branch 'master' of git://git.haskell.org/packages/Cabal

Edward's patch to stop using old file style package dbs.
.travis.yml: Add GHC 7.2.2.
Accept duplicates when they're all the same.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Add instance Binary LocalBuildInfo
Use Binary instance to save/restore dist/setup-config
Load binary LocalBuildInfo in package-tests

PackageTests has its own version of getPersistBuildConfig which does not
check which version of Cabal created dist/setup-config. Now that the
LocalBuildInfo is written with Binary, this version needed to be
updated, too.
Clarify Cabal dependencies policy

[ci-skip]
Merge pull request #2076 from ttuegel/binary-lbi

Use Binary to save/restore persistent build config
Exec tests no longer fail if there isn't a sandbox

The tests which delete the sandbox, now check for its existence before
deleting it. This prevents erroneous test failures when the tests are first
run or any time that the sandbox has been deleted.
cabal-install tests use locally built cabal

When running the cabal-install tests, we want to run against the locally built
cabal executable, not any other cabal executable which may be installed.

If we are 1) following the advice of building cabal with `cabal build` (as
opposed to installing it into a sandbox with `cabal install`) and 2) not using
a non-default build directory, the locally built cabal will be located at
`dist/build/cabal/cabal`.

By adding the directory `dist/build/cabal` to the program search path we will
pick up any cabal executable there in preference to any other on the $PATH.

For most users, I expect that this will remove any surprises with an
unexpected cabal executable being selected for running the tests. It will be
sufficient to allow the tests to run on Travis.

For users who have been installing cabal into a sandbox, this change could
result in an older cabal executable being selected. It's not clear to me how
to solve this issue or whether anyone will experience this.
Enable cabal-install tests on travis
Merge pull request #2087 from benarmston/improve-cabal-install-tests

Improve cabal install tests
Support the 1.5 release of 'time'.

Fixes #2100.