That is, the --with-$PROG program locations, the --$PROG-option(s)
program arguments and the --extra-prog-path search paths. These can be
passed on the command line or specified in the cabal.project file.

In the project file they can be specified for all local package or on a
per-package basis.

The compiler and its related programs are handled specially. Their
location cannot be specified independently for each package. A
subsequent patch will add the checks for this. Otherwise we just pass
the program config though.

Program options specified on the command line currently apply to all
local packages, not just the targets of the command. We may want to
revisit this.

Not needed immediately, but we'll need it eventually to avoid import
cycles later. No other changes, just moving things around and pruning
imports and language extensions.

The ProgramDb in the ElaboratedSharedConfig actually only ever contains
the programs configured by the compiler, and this is the way it will
remain, so rename to clarify that usage.

Config for other non-compiler programs will be handled differently. This
makes sense because the compiler (and programs) have to be shared
between all packages, while for non-compiler programs it's possible in
principle to use different versions for different packages within a
project. Thus it's not possible to have a single shared ProgramDb for
all programs for all packages (other than for the compiler).

The solverSettingFlagAssignment does not need to be eliminated, it's ok
to have both, but make a note that it does need validating at some
point.

We need to be able to specify program options and locations on a
per-pakage basis. Of course we can still specify them for all local
packages.

Note that these options are not actually used yet, which is why this
patch can be so small. Using them is next.

Move the FlagAssignment from the project-wide all-packages config to the
per-package config.

Initially it had been easier to do it globally since it gets used as a
solver setting rather than as the other per-package config items, but
obviously it is supposed to be per-package.

So the flags field in the config top-level now applies to all local
packages. And it can also be specified in package-specific sections.

We don't yet check that any of the flags specified actually make sense
for either the local packages or for the specific packages.

It's a Map PackageName PackageConfig (or LegacyPackageConfig) so the
correct monoid instance is to merge the PackageConfig values.

These are newtype wrappers with different Monoid instances. This is for
following our more recent approach to the Monoid instances of our config
types where rather than having custom mappen methods, we derive generic
Monoid/Semigroup instances and rely on using special types like NubList
for individual fields that need different mappend behaviour.

The Map type has mappend behaviour that is not usually what we want for
our configuration types. The normal Map mappend prefers the first
argument over the second when keys overlap between the two maps. We
normally want later things to either override or to extend, like our
normal Flag (like Last) monoid or list monoid. So MapLast is a Map with
Flag/Last-like behaviour, ie flip Map.union, while MapMappend is a Map
that merges values when keys overlap, ie Map.unionWith (<>). The latter
helps when the Map values are lists or further records.

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