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>

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'.

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

Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world.  Private
libraries are signified using the

    library foo

stanza.  Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)

This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)

There is a "default" library which is identified by the fact
that its library name coincides with the package name.  There
are some new convenience functions to permit referencing this.

There are a few latent bugs in this commit which are fixed
in later commits in this patchset.  (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)

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

A package path now consists of a namespace and a qualifier. The namespace is
either DefaultNamespace or Independent _i_, for some _i_; this is used for
independent top-level goals. Then the qualifier is either Unqualified
(default), Setup _pn_ for the setup dependencies of package _pn_, or Base _pn_,
for a dependency on base by package _pn_ (used only when we detect the presence
of a base shim). Qualifiers are not tested anymore.

This avoids non-termination in the solver. The unit tests now pass.

In #3170 we introduced a cycle check to the solver. This check is necessary to
reject cycling solutions (which would previously have resulted in an internal
error when we verify the install plan). However, this by itself is not
sufficient. If we have a cycle through setup dependencies, the solver loops
because it starts building an infinite tree. This is explained in detail in

In this commit we just add some unit tests that provide a minimal example that
exposes the bug.

The alias is a shorthand for 'SourcePackage UnresolvedPkgLoc' which is
used all over the place.

This is a step towards breaking the dependency from the modular
solver on cabal-install.

When solving, we now discard plans that would involve packages with a
pkgconfig-depends constraint which is not satisfiable with the current
set of installed packages (as listed by pkg-config --list-all).

This fixes https://github.com/haskell/cabal/issues/3016.

It is possible (in principle, although it should be basically impossible
in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to
execute for various reasons, in particular because N is too large, so
the command line becomes too long for the operating system limits.

If this happens, revert to the previous behavior of accepting any
install plan, regardless of any pkgconfig-depends constraints.

GHC 8.0 is switching the state sponsored way to specify
linker names from -this-package-key to -this-unit-id, so
it behooves us to use the right one.  But it didn't make
much sense to pass ComponentIds to a flag named UnitId,
so I went ahead and finished a (planned) refactoring
to distinguish ComponentIds from UnitIds.

At the moment, there is NO difference between a ComponentId
and a UnitId; they are identical.  But semantically, a
component ID records what sources/flags we chose (giving us enough
information to typecheck a package), whereas a unit ID records
the component ID as well as how holes were instantiated
(giving us enough information to build it.)  MOST code
in the Cabal library wants unit IDs, but there are a few
places (macros and configuration) where we really do
want a component ID.

Some other refactorings that got caught up in here:

    - Changed the type of componentCompatPackageKey to String, reflecting the
      fact that it's not truly a UnitId or ComponentId.

    - Changed the behavior of CURRENT_PACKAGE_KEY to unconditionally
      give the compatibility package key, which is actually what you
      want if you're using it for the template Haskell trick.  I also
      added a CURRENT_COMPONENT_ID macro for the actual component ID,
      which is something that the Cabal test-suite will find useful.

    - Added the correct feature test for GHC 8.0 ("Uses unit IDs").

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

This default is consistent with Cabal.

'DSL.exResolve' now takes a 'Maybe [Extension]' for supported extensions and
a 'Maybe [Language]' for supported languages.  'Nothing' means that
extensions/languages are not checked by the solver, and 'Just []' means that
no extensions/languages are allowed.

This also includes modifications to the solver testing DSL and the
testing functions.

This is necessary for merging PR #2732.

Today in Cabal, when you build and install a package, it is
uniquely identified using an InstalledPackageId which is computed
using the ABI hash of the library that was installed.  There
are few problems with doing it this way:

    - In a Nix-like world, we should instead uniquely identify
      build products by some sort of hash on the inputs to the
      compilation (source files, dependencies, flags).  The ABI
      hash doesn't capture any of this!

    - An InstalledPackageId suggests that we can uniquely identify
      build products by hashing the source and dependencies of
      a package as a whole.  But Cabal packages contain many components:
      a library, test suite, executables, etc.  Currently, when
      we say InstalledPackageId, we are really just talking about
      the dependencies of the library; however, this is unacceptable
      if a Cabal package can install multiple libraries; we need
      different identifiers for each.

    - We've also needed to compute another ID, which we've called
      the "package key", which is to be used for linker symbols
      and type equality GHC-side.  It is confusing what the distinction
      between this ID and InstalledPackageIds are; the main reason
      we needed another ID was because the package key was needed
      prior to compilation, whereas the ABI hash was only available
      afterwards.

This patch replaces InstalledPackageId and PackageKey with a
new identifier called ComponentId, which has the following
properties:

    - It is computed per-component, and consists of a package
      name, package version, hash of the ComponentIds
      of the dependencies it is built against, and the name
      of the component.  For example, "foo-0.1-abcdef" continues
      to identify the library of package foo-0.1, but
      "foo-0.1-123455-foo.exe" would identify the executable,
      and "foo-0.1-abcdef-bar" would identify a private sub-library
      named bar.

    - It is passed to GHC to be used for linker symbols and
      type equality.  So as far as GHC is concerned, this is
      the end-all be-all identifier.

    - Cabal the library has a simple, default routine for computing
      a ComponentId which DOES NOT hash source code;
      in a later patch Duncan is working on, cabal-install can
      specify a more detailed ComponentId for a package
      to be built with.

Here are some knock-on effects:

    - 'id' is a ComponentId

    - 'depends' is now a list of ComponentIds

    - New 'abi' field to record what the ABI of a unit is (as it is no longer
      computed by looking at the output of ghc --abi-hash).

    - The 'HasInstalledPackageId' typeclass is renamed to
      'HasComponentId'.

    - GHC 7.10 has explicit compatibility handling with
      a 'compatPackageKey' (an 'ComponentId') which is
      in a compatible format.  The value of this is read out
      from the 'key' field.

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

This commit adds the sources of constraints to debugging and error messages,
e.g., "main config file" or "command line flag".

Duncan Coutts authored 9 years ago and Mikhail Glushenkov committed 9 years ago

So rather than the concrete InstalledPackageInfo and ConfiguredPackage,
the InstallPlan and PlanPackage are parameterised by the type of the
installed package, the source package and the types used for successful
and unsucessful build results.

In GHC 7.10, Cabal always generate package keys, including in
cases where Backpack was involved (e.g. --instantiated-with).
In fact, in these case, GHC needs to be able to generate the
package key (because it will often make a substitution on the
instantiation, and needs to know if this identity coincides with
anything else we've seen previously).

Thus, we introduce a new notion, the 'LibraryName', which
is JUST the non-Backpack portion of a package key.  For ordinary
packages that are definite, a 'LibraryName' is simply
the 'PackageId' plus 'PackageKey'; for indefinite Backpack packages,
when a package gets instantiatied, it may end up with different
'PackageKey's even though the 'LibraryName' stays the same.
'LibraryName's can be computed purely by Cabal.

This patch:

    - Defines library name, which are the source package ID plus
      a hash of all the source package ID and the library names of external,
      textual dependencies,

    - Redefines the package key to be JUST the hash portion of a
      library name, in the case that Backpack is not used,

    - Records the library name in InstalledPackageInfo.

Note: the source package ID is included both externally (so the library
name is a useful handle to refer to package) and internally (so the
hash can stand alone as the package key.)

A major refactoring which is part of this commit is moving package keys/library
names from LocalBuildInfo to LibComponentBuildInfo.  If you have an LBI, you can
still extract a package key/library name using the new
localPackageKey/localLibraryName function (which looks through the
ComponentBuildInfos of a LocalBuildInfo for the library in question).  This is
conceptually cleaner for two reasons:

    1. Only dependencies of the *library* are counted as part
    of the library name, as opposed to *all* dependencies which
    we previously used.

    2. A library name doesn't really mean much for an executable,
    or a test suite, since no one else will have to link against
    them.  So we can fall back on something simpler.

A more minor refactoring is the 'LibraryName' type, which was
previously defined by LocalBuildInfo and generally looked something
like "HSprocess-0.1-XXXX".  We change the meaning of 'LibraryName'
to be "process-0.1-XXXX" (thus we have to insert some HS additions
in the code) and eliminate componentLibraries, thus assuming that
there is only ONE Haskell library (which was the case.)  So
we remove a little bit of generality and in return get code
that is much easier to read.  (The only downside is GHC's hack
to split DLLs into multiples has to be adjusted slightly, but
this is not a big price to pay.)

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

Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10817840.

This address @23Skidoo's comment
https://github.com/haskell/cabal/pull/2500#issuecomment-8703532

Since we didn't really have a unit test setup for the solver yet, this
introduces some basic tests for solver, as well as tests for independent goals
specifically.