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>

--assume-deps-up-to-date lets you compile a single component without
building its dependencies.

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

This will help us when we implement 'build --assume-deps-up-to-date":
after configuration, we will assume that there is some (consistent)
inplace database.

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

Fixes bug on Windows.

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

Monitor the pkg-config db for changes

We use the pkg-config db as an input for the solver, so we ought to
monitor it for changes. The pkg-config tool makes this possible, if not
totally trivial.

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

The three commands are all implemeted in terms of the planning and
execution infrastracture added previously. The orchestration of that
infrastructure is shared between the commands in another module.

Also add a new CLI target parsing/recognising/disambiguating module,
similar to the one in the Cabal lib used for the 'build' command, but
extended to cover multiple packages in a project rather than just
components within a package.

This is (mostly) hvr's code.

It produces an external representation of the elaborated install plan.
The intention is for it to be used by external tools, editors etc, to
find out relevant details of the project and package configuration and
environment. It is updated whenever the elaborated install plan
changes, so it always reflects the current state.

Currently it only includes a modest subset of the details from the
elaborated install plan, but the goal is to include all relevant details
in a mostly-stable JSON format.

Currently it's based on the elaborated install plan prior to improving
the plan with packages from the store, but ultimately it will need to
include information from both before and after the 'improvement' phase.

As a refactoring, this moves allPackageSourceFiles from
Distribution.Client.Sandbox.Timestamp to
Distribution.Client.SrcDist, makes it thread safe, and has
it return files relative to the source directory.

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

You're not allowed to specify a different compiler program for different
packages within the same project. Given that in general we allow
specifying config about programs on a per-package basis this needs a
specific check.

Also add a place and a TODO for Future work in this area which is to
check up front that we can find the programs and to monitor them for
changes. Also, currently none of the program config ends up in the
package hashes, so it doesn't cause them to be rebuilt.

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.