Both relative and absolute paths. That is, things like:

packages: this/
          ~/hacking/that/

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>

Additionally, ABI computation no longer requires successful
registration, so you can generate scripts in any order.

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

This commit adjusts cabal-install so that it is able to handle
--gen-pkg-config generating a directory of registration
scripts rather than a single one.  I'll add this functionality
in the next commit.

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

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

'cabal test': don't fail on no test suites.

Test suite: create symlinks as needed.

Pass short path names to configure scripts on Windows.

Cabal.cabal: Add missing files

Fixes #3215.

Fixes #3190.

Fixes #3185.

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>

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

Disable fast finish as it is buggy w.r.t. notifications https://github.com/travis-ci/travis-ci/issues/4928

 [ci skip]

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>

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

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

Compute 'UnitId' when we compute a 'ConfiguredPackage';
consequently, we can eliminate 'FakeMap' (finally!)
There is one hack remaining, which is that 'SolverInstallPlan'
gins up fake unit IDs so that it can be keyed on UnitIds.
But this data structure exists only very briefly before
being converted into an 'InstallPlan' or 'ElaboratedInstallPlan'.

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

Currently, dependency solving immediately produces an 'InstallPlan'
which is then consumed by cabal install, or elaborated into
an 'ElaboratedInstallPlan' for cabal new-build.  However, this
translation is awkward, because the dependency solver knows nothing
about 'UnitId's, yet an 'InstallPlan' must indexed by 'UnitId's.
So there's a bit of faffing around to generate a "fake" unit id
to satisfy the interface, and then eventually correct it to the
right one.

So this patch starts moving us in a better direction, by introducing
a 'SolverInstallPlan', 'SolverPackage' and 'SolverId', intended
to be generated by the solver.  Then 'configureInstallPlan' or
'elaborateInstallPlan' elaborate this representation into the
representation needed by the destination.

The next step will be to generate the 'UnitId' during
'configureInstallPlan', and then we can get rid of the fake map
(so only Solver data types generate a fake identity, which
is only temporary until we generate 'UnitId's.)

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

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

Simplify representation of test suites in the solver DSL

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

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

Previously, ReadyPackage was a ConfiguredPackage elaborated with
a dependencies data structure which had InstalledPackageInfo
rather than ConfiguredId. Well, it turned out that we only
used the data from ConfiguredId! So that extra info is useless.

Instead, ReadyPackage is now purely a newtype wrapper for type
safety; a reminder that not all ConfiguredPackages can be built,
only the ready ones.

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>

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

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

Limit qualifier depth

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

This commit removes the 'ExTest' constructor from 'ExampleDependency'.
Test dependencies are now represented using the same
'ExampleDependency' constructors as library dependencies.  The only
difference between dependencies of different components is that they
are placed under different keys in 'D.C.ComponentDeps.ComponentDeps'.