Edward Z. Yang authored 10 years ago and Mikhail Glushenkov committed 10 years ago

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

The 'user-config' command allows pseudo-diff-ing and updating of the
user's ~/.cabal/config file. The diff is against what cabal would
generated if the user config file did not exist and the update
command overlays the user's existing settings over the current
version of the default settings and writes it back to ~/.cabal/config.

Closes: #2159

Some Cabal API clients apparently use `foldl mappend` on large lists of
`GhcOptions` records. Fixes #2110.

Fixes #2089.

Fixes #2135.

User config fields like 'remote-repo', 'extra-prog-path' and 'build-summary'
were lists, which mean that when two SavedConfig types were concatentated
the lists for these fields were concatenated, resulting in duplicate entries.
Duplicated entries in these fields simply don't make sense, so we swicth to
NubList for these fields.

Closes: #2160

* The function has type 'Repo -> IO Double'.
* It returns the age in days as a Double.
* Places that expected the age as an Int have been updated.
* Builds with ghc 7.4.2 and 7.8.3.

These values can be useful for debugging cabal issues.

database install

This changes how the SCOPE_OF_INSTALLATION variable is used to provide
an alternate way of running bootstrap.sh which can install
cabal-install to a separate prefix and package database without
altering the user's package database or using it. The idea with this
is to improve the repeatability of automatically installing ghc, cabal
and other haskell independently of the current standard installation
or the user's main package database.

Usage example:

ghc-pkg init /home/jake/test_cabal/
SCOPE_OF_INSTALLATION='--global --package-db=/home/jake/test_cabal/packagedb' PREFIX=/home/jake/test_cabal/prefix ./bootstrap.sh

If you don't override the SCOPE_OF_INSTALLATION variable, bootstrap.sh
works as before.

tarballs if these tarballs are already present.

A couple of settings were filtered out since
74cb2909 including
`configure-option`. However, it turns out you may want to
persist some options to `configure`, such as e.g.

  --configure-option=--build=x86_64-w64-mingw32

when working in a Cygwin host environment, but using a Mingw
toolchain (such as the one bundled with the Windows GHC bindist).

Approved by @dcoutts

This reverts commit f59bab10.

Revert "Switch InstallPlan over to using IPID-indexed PackageIndex."

This reverts commit 6465d174.

1. When we union PackageIndexes together, prefer the later one.
   This idiom is used when we update the processing-state of
   packages in an InstallPlan.

2. dependencyInconsistencies' was missing a number of indirections
   through the fakeMap, so in some cases we incorrectly concluded
   packages were not equal when they were.

3. We need to initialize the fakeMap with any pre-installed packages,
   otherwise the invariant check for configured-packages will fail.

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

NETWORKURI_VER_REGEXP should be NETWORK_URI_VER_REGEXP

Unlike GHC, Cabal will still try to find a globally consistent choice for
all package names, i.e. this does *not* implement private dependencies.

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

Command "cabal sandbox --list-options" doesn't list subcommands of
"cabal sandbox", but "cabal help sandbox" does. It turns out that it is
easy to parse its output using sed and as such can be added to list of
words for completion.

Fixes #2100.

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.

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.

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>

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>