Use import list to hide new System.Exit.die

Starting with GHC 7.10 (and soon GHC HEAD), System.Exit exports the new `die`
which would clash with Cabal's own `die`. See also

  https://ghc.haskell.org/trac/ghc/ticket/9016

For more details.

(cherry picked from commit 322ddbc019bf2386897b9b9be7d534cc0e4d39c1)
Revert "'cabal configure': honor the '--constraint' flag."

This commit caused cabal to no longer try to run configure if the
dependency solver failed, causing e.g. the containers test suite to no
longer build.

This reverts commit 16836efe96c6e7deb80ef9103edc236f872ae090.
Add OS and arch to HTTP user-agent string

This makes the HTTP user-agent field look like so:

    User-Agent: cabal-install/1.21.0.0 (linux; x86_64)

This allows us to gather more statistics about our user-base as
with the current user-agent string we can only do a rough break-down by
cabal-install version numbers.

(cherry picked from commit bd0fcd55d7cc98e9155569684f9a749938360c0c)
Platform dependent search path separator

When using cabal exec on Windows, it would give an error such as:

ghc.exe: can't find a package database at
C:\Users\tchakkazulu\path\to\dir\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d:C:\Program
Files (x86)\Haskell Platform\2013.2.0.0\lib\package.conf.d

(cherry picked from commit 12deea33d0b3c4090abe47ec5f30ae57217e10d0)

Conflicts:
	cabal-install/Main.hs
Bump cabal-install version number to 1.20.0.1
Add --enable-{tests,benchmarks} to freeze command

If they are present the dependencies of all test and benchmark stanzas are
included in the frozen set of dependencies.
Tests for the freeze command

Introduced a new test-suite, package-tests, which is intended for black-box
testing of the cabal binary.

The `PackageTests` module determines which cabal binary is to be tested and
runs the tests passing each of them the path to that binary. The binary is the
first cabal binary found on the path. To test a different binary, adjust the
PATH environment variable.

The `PackageTests.PackageTester` module contains common routines to execute
the cabal binary and check its results.

Finally, the `PackageTests.Freeze.Check` command contains some tests for the
freeze command.
PackageTester uses D.S.Utils.printRawCommandAndArgs
Increase defaultMaxBackjumps to 2000 (from 200).

As suggested by Anders Löh in #1780.

(cherry picked from commit e2b481a070aa95454547dad9ff6e505454194487)
Fix a flag-handling bug related to #1855.

This was an innocent-looking but severe bug that was triggered for manual
flags in certain circumstances: if both choices of a manual flag are
already invalidated by other decisions, then the old code was removing
the nodes underneath the flag completely. As a result, there's a node
with no children rather than a node with two failure-children. The
fail-nodes carry important information that is used to compute how far
we can backtrack. If this information is removed, strange things happen.
Fix flag goal generation (and hopefully #1855).

Package flags generate (Boolean) goals. Package flags can be dependent
on one another, in situations such as this one:

  if flag(a)
    ...
  else
    if flag(b)
      ...
    else
      ...

In such a scenario, it's important to record that flag b depends on flag
a. This affects conflict set generation. If something fails due to the
choice of flag b, we should not backjump beyond flag a.

While the code handling the proper insertion of goals with their correct
dependencies was always there, it was accidentally overridden by another
piece of code that created flag goals (without dependencies) for all
flags defined in a package. The reason I add flag goals separately is
because not all paths in the decision tree may contain choices for all
flags of a package. For example, if a is chosen to be True in the
example above, b does not occur at all. But flag choices may still
affect other things that aren't visible to the solver (directory
choices, exposed modules, ...), so all flags declared should always be
chosen explicitly. So we want to keep adding all flags declared in a
package as dummies, but we have to make sure to do so *before* adding
the actual dependency tree. This way, while traversing the dependency
tree, the ones occurring in dependencies will be added again, overriding
the dummies, rather than the other way round (which we used to have
before, where the dummies were overwriting the more informative
versions).
Treat flags with much less priority.

This implements two changes:

(1) Flag choices are deferred whenever possible.
(2) If a package appears on both branches of a conditional, the
    unconstrained package is lifted out of the conditional.

In combination, we're trying to achieve that the solver should pick
a package before the flag, and thereby e.g. respect installed package
versions.

This is adequate in the common use case that flags are simply
representing a disjunction, and should be rather weak.

We'll have to see what happens in the few other situations where flags
are really representing optional features. I'd expect, however, that
in such situations there are targets in one branch, and not the other.
Then the flag choice would still happen prior to the corresponding
target.
Configurable strong/weak flags.

This adds a mechanism in the modular solver to store whether a flag
is "strong" or "weak". A weak flag is deferred during solving, a strong
flag is not.

By default, flags are now weak unless they're manual. This is a change
in behaviour, but I think it's probably the better default, because many
automatic flags are used to figure out what's on the system rather than
to impose hard constraints.

There's a new flag --strong-flags that restores the old behaviour. I do
not think such a global flag is particularly useful, but it may be
of interest to compare build plans between the new and old behaviour.

With these preparations, it's easy to make the distinction between
strong and weak flags more sophisticated. We can either add more
heuristics as to when flags should be treated as strong or weak, or we
can add syntax to .cabal files that allows package authors to specify
explicitly how they intend a flag to behave.

This is related to various cabal-install issues, e.g. #1831, #1864,
and #1877.
Merge pull request #1853 from benarmston/freeze-test-and-benchmark-deps

Add --enable-{tests,benchmarks} to freeze command
Merge branch 'solver-flag-handling-fixes' of https://github.com/kosmikus/cabal
Fix a flag-handling bug related to #1855.

This was an innocent-looking but severe bug that was triggered for manual
flags in certain circumstances: if both choices of a manual flag are
already invalidated by other decisions, then the old code was removing
the nodes underneath the flag completely. As a result, there's a node
with no children rather than a node with two failure-children. The
fail-nodes carry important information that is used to compute how far
we can backtrack. If this information is removed, strange things happen.

(cherry picked from commit 3e33a0f39807655f0245fea43b4f1455f6198c41)
Fix flag goal generation (and hopefully #1855).

Package flags generate (Boolean) goals. Package flags can be dependent
on one another, in situations such as this one:

  if flag(a)
    ...
  else
    if flag(b)
      ...
    else
      ...

In such a scenario, it's important to record that flag b depends on flag
a. This affects conflict set generation. If something fails due to the
choice of flag b, we should not backjump beyond flag a.

While the code handling the proper insertion of goals with their correct
dependencies was always there, it was accidentally overridden by another
piece of code that created flag goals (without dependencies) for all
flags defined in a package. The reason I add flag goals separately is
because not all paths in the decision tree may contain choices for all
flags of a package. For example, if a is chosen to be True in the
example above, b does not occur at all. But flag choices may still
affect other things that aren't visible to the solver (directory
choices, exposed modules, ...), so all flags declared should always be
chosen explicitly. So we want to keep adding all flags declared in a
package as dummies, but we have to make sure to do so *before* adding
the actual dependency tree. This way, while traversing the dependency
tree, the ones occurring in dependencies will be added again, overriding
the dummies, rather than the other way round (which we used to have
before, where the dummies were overwriting the more informative
versions).

(cherry picked from commit a51b8378d516d5bd7cb4bbc8ed4317137b3c96c1)
Merge branch 'defer-flags' of https://github.com/kosmikus/cabal

Conflicts:
	cabal-install/Distribution/Client/Freeze.hs
Always stream test output concurrently

Issue #1810. Some test suites would freeze if invoked with
`--show-details=always` instead of `--show-details=streaming` because
output would build up in the pipe without being cleared. This corrects
the issue by forcing the length of the output string in another thread.
Merge pull request #1882 from ttuegel/tests-freeze

Always stream test output concurrently