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.

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>

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

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

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.

Matthias Fischmann authored 9 years ago and Duncan Coutts committed 9 years ago

Fix: 7.4.2 compat.

PVP compliance: upper version bound.

Revert noise and relax zlib min version back to 0.5.3 (part 1/2).

Revert noise and relax zlib min version back to 0.5.3 (part 2/2).

Test cases for maybeDecompress.

Use edsko's implementation of maybeDecompress; add test case.

Fixup.

maybeDecompress: test suite work-around.

Cleanup.

Relax zlib upper bound.

maybeDecompress: add mysteriously failing test cases.

7.4 compat for test cases.

e.g. cabal install https://example.com/foo-1.0.tar.gz

The initial patch would always try to use HTTPS, even when the repo
specified to use HTTP. This works for the central community hackage
but obviously does not work in general.

The new logic is that we always follow what is specified for the
remote repo in the config, except for built-in known repos (currently
just the central community hackage) where we mark them as also
supporting https. For upload when uploading to such a marked repo
then we will try https and will complain if the plain-http impl was
selected automatically (but it's ok if selected manually).

This patch also changes things so that for http urls on download, we
stick to the builtin http impl by default, and only use the external
ones if https support is required (i.e. because the repo was
configured to use an https url)

Move utils into other Util modules.
Reformat all code to 80 cols.
Reorder code and add more comments.
Use long form style program args, e.g. --silent rather than -s
Finish implementation of form upload with wget
Fix reporting of server error messages for upload (curl & builtin)
Implement collecting of ETags for curl and wget.
Fix wget for case of 304 not modified response (wget uses exit code 8).
Rework transport configuration phase.

gershomb authored 9 years ago and Duncan Coutts committed 9 years ago

Supports both uploading and downloading.
Basic built-in HTTP is still supported.

This will be useful for adding crypto credentials without people having
to update their config files.

Also useful point to add any other special casing for known repos.

Will need a later check to validate the repo info, e.g. that it's a
supported url scheme and is an absolute URI.

Fixes #2484. The 'builddir' option may now be specified in cabal.config
as well. It will also be read from the CABAL_BUILDDIR environment
variable, if set. The order of precedence (highest to lowest) is:
1. --builddir command line option
2. CABAL_BUILDDIR environment variable
3. cabal.config setting

The tests now read cabal.config strictly so that the file is closed by the time
it is deleted for the next test.

Without this change, differences in filename capitalization caused "cabal
sandbox delete" to fail with this error message when used with a default
sandbox on Windows:

cabal.exe: Non-default sandbox location used:
'C:\folder\.cabal-sandbox'.
Assuming a shared sandbox. Please delete
'C:\folder\.cabal-sandbox' manually.

This commit also allows the cabal-install package tests that delete sandboxes
to run on Windows.

This change allows the tests "can run executables installed in the sandbox" and
"adds the sandbox bin directory to the PATH" to run on Windows by removing the
executable name from the required error message.