GitLab

BC note: renamed type PackageIndex :: * to InstalledPackageIndex.

The intent is to have cabal-install use this package index in order to
track information about compilation in progress.  We introduce a new
PackageInstalled type-class to keep track of data types which have their
IDs and dependency graphs in InstalledPackageId.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

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

Ezyang test fixes

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

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

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

So that the 'install_from_tarball' build bot step doesn't try to use the old
1.21 snapshot that comes with GHC HEAD.

Accommodate network/network-uri split

This information is passed via 'dist/setup-config'.

See https://github.com/haskell/cabal/issues/2046#issuecomment-53034455.

Thanks to A. Bram Neijt (see #2045).

reword help text in allow-newer

See https://github.com/haskell/cabal/issues/1721#issuecomment-52210898

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>