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

It wasn't used within the InstallPlan, but it had accessors and those
were used in a few places. Just pass them into those few places that
need it.

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.

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

Fewer shared types makes the code easier to grok and navigate.

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

No longer needed anywhere else.

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

Removed from the InstallPlan and solver interface.
The InstalledPackage is really just there for the benefit of the old
TopDown solver which needs to know source deps.

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

Rather than directly reusing the InstallPlan.PlanPackage type which has
more cases and which we'd like to generalise somewhat.

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

The InstallPlan can be generalised by abstracting over the specific
package types. The only thing that really relies on a lot of the
details of the concrete ConfiguredPackage type is the bit that
validates them individually (as opposed to validating packages
within the plan in relation to other packages, graph structure etc).

So as a prelude to generalising the InstallPlan, move the checks
on the ConfiguredPackage into the Dependency module and use them
when checking the output of the solver.

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

It was in the PackageIndex module but it was unused there and it
being there was just confusing.

This reverts commit bd7bbd70, reversing
changes made to d8fa4618.

Ensure that OS X framework headers are in include path

This fixes #2689.

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

cabal init: generate less for PublicDomain

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>

Update HACKING.md

Add `--enable-tests` for cabal-install setup instructions

Exit with an error if $CABAL_SANDBOX_CONFIG does not point to extant file

Add support for automatic profiling detail levels, with reasonable defaults

Support pure test packages (issue #1186)

New flags: --profiling-detail and --library-profiling-detail.
When profiling is enabled (by the existing flags) then these flags
are taken into account to set the profiling detail level.

The levels are:
 none
 default
 exported-functions
 toplevel-functions
 all-functions

The default value for ghc for libraries is exported-functions and
for exes is toplevel-functions.

On GHC these levels correspond to the -fprof-auto* flags. The
ghc-prof-options will override this (just because it's passed to
ghc at the end).

maybeDecompress: bail on all errors at the beginning of the stream with zlib < 0.6

Fix #2704

Code branch with zlib <0.6 cannot recognise the uncompressed input.

Add missing test modules

This commit relaxes D.PackageDescription.Check.checkConfiguredPackage so that it
only warns when a package declares no executables, libraries, tests, or
benchmarks.  Similarly, it relaxes the check during build to only require one
component that is buildable and enabled.  Install now requires an executable or
library.

Use the version macros when building Setup.hs

The design called for allowing deps to be specified, and for the
Setup.hs to be able to use the same version macros as in other code.
This patch completes that second part.