idontgetoutmuch authored Sep 18, 2013 and Duncan Coutts committed Oct 25, 2013

that the exact packages are installed rather than letting cabal choose
for itself (potentially choosing the package with the incorrect
hash). Closes: https://github.com/haskell/cabal/issues/1460.

TillmannRendel authored Sep 08, 2013 and Duncan Coutts committed Oct 25, 2013

The goal is to learn the installed package id of the package we just
installed, as necessary for #1860. We achieve this by inserting an
additional call to "setup register" that produces the installed package
information in a file. We read and parse that file and could now return
the installed package id, but it is not clear what interface would be
appropriate.

Rather than when /= latest. So we'll no longer report things like:

  hdevtools-0.1.0.6 (latest: 0.1.0.5) (new package)

We don't need to tell people they're not using the latest version when
they're actually using a later version than the one available (e.g.
it's installed locally and not available from the remote server).

Reported by bennofs

Fixes #1522.

Helps to disambiguate Cabal's compat modules from cabal-install's.

See #1362.

Before: '--libsubdir=$arch-$os-$compiler/$pkgid'.
After:  '--libsubdir=i386-linux-ghc-7.4.2/lifted-base-0.2.1.0'.

Otherwise libs with 'build-type: Custom' get installed under
'$prefix/lib/$pkgname' instead of '$prefix/lib/$arch-$compiler-$os/$pkgname' if
the setup script is compiled against Cabal < 1.17.

Add new functions 'withTempFileEx' and 'withTempDirectoryEx' instead.

Fixes #1387.

handleIO and throwIOIO in the cabal-install compat module were
completely unused, so they're just binned.

IOException, SomeException and onException are now just used from
Control.Exception, since these days it's available on all supported
build configurations.

There are some more functions which can be removed, but these are the
easiest and least invasive.

With 'install -j' it can be a bit hard to tell where the packages are
installed. This will be reworked once we get a unified dynamic UI for 'install'.

Fixes #1197.

This patch is a bit large because it includes several related changes:

1) Remove 'installUseSandbox' from 'InstallFlags' and pass 'useSandbox' as an
additional argument instead.

2) Instead of calling 'reinstallAddSourceDeps' from 'installAction', always pass
'SandboxPackageInfo' to 'install'.

3) Set the timestamps of newly-added add-source deps to 0 in the timestamp file.

4) Move the timestamp file update to 'postInstallActions' from
'withModifiedDeps'. This way, the timestamps are updated even when the user runs
'install --only-dependencies' or 'install some-add-source-dep-package-id'.

Otherwise 'install --reinstall' in a sandbox reinstall the contents of the whole
sandbox.

Previously, we used a hack for reinstalling reverse dependencies: we created an
install plan for the sandboxed package and the modified add-source deps and then
pruned the sandboxed package from it. This missed those revdeps that the
sandboxed package didn't depend on and also broke the sandboxed package if it
was installed in the sandboxed package DB (see #1229).

This commit replaces that hack with a more principled approach: we create a plan
for the whole environment (all packages installed in the sandbox), constraining
the modified add-source deps to be reinstalled and the already installed
packages to be preferably not.

Fixes #1229.

Reverts 7b2e3630. Instead of temporarily setting
'configUserInstall' to 'False' in various places, we now just check that we're
not in a sandbox when deciding whether we should use 'rootCmd'.

Fixes #1271.

Removes the uses of buildPlatform from D.C.Install.

Return Maybe Platform as part of compiler configure, and place it in LocalBuildInfo as hostPlatform.
GHC infers the platform form ghc --info using new 'platformFromTriple' function. Other compilers return Nothing, which triggers fallback to old behavior of using buildPlatform. hostPlatform is then threaded through to initialPathTemplateEnv.

This means tweaking CPP conditionals and file pragmas to remove handling
of compilers other than GHC, and GHC versions before LANGUAGE pragmas
existed.

Splits 'D.C.Install.install' into three parts:

    * makeInstallContext - load common data
    * makeInstallPlan    - produce the install plan
    * processInstallPlan - actually perform the installations

This allows to manipulate the install plan produced with 'makeInstallPlan'
before performing the installations with 'processInstallPlan'. The high-level
'install' action is still present; most clients should use it instead.

The name 'InstallContext' will be used for common data shared between
lower-level install functions.