Prompt source directory in cabal init
Create source directroies with cabal init
Merge pull request #1989 from fujimura/prompt-source-directory

Ask source directory in cabal init
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>
Merge pull request #2021 from thoughtpolice/amp

Fix build in the face of Applicative-Monad
Comment.

See #2023.
fix `sdist' tar invocation to be compatible with Solaris' tar
Merge pull request #2026 from kgardas/master

fix `sdist' tar invocation to be compatible with Solaris' tar
Add flag --print-id for ./Setup register, outputs installed package ID

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Implement package keys, distinguishing packages built with different deps/flags

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>
Add $pkgkey template variable, and use it for install paths.

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>
Disable reinstalls with distinct package keys for now.

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>
Fix regression for V09 test library handling.

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>
Merge pull request #2002 from ezyang/ezyang-pkg-key

Support multiple instances of package ID in database with different deps
merge master
Add package key support to ghcjs branch