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

Andres Löh authored 9 years ago and kristenk committed 9 years ago

When configuring a package, the condition trees in the package
descriptions are evaluated according to the known configuration
and flag assignment.

During this process, it becomes also known whether a component
has its "Buildable" flag set to True or False. We now disregard
all dependencies of non-buildable components.

Andres Löh authored 9 years ago and kristenk committed 9 years ago

When doing the index conversion prior to dependency solving, we now
consider the "Buildable" flag for package components.  In particular, if
the "Buildable" flag of a component is "True" only under certain
conditions, then all build dependencies of that component will be placed
under the same conditions.

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

Remove dead code in modular solver

Introduce RepoContext

don't special-case versions with leading zeroes

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>

Cabal's LibV09 support has always been a bit skeevy.  The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable.  In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.

Old versions of Cabal did something very skeevy here:  they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.

Consequently, a lot of bad things could happen (both of which I've
added tests for):

    1. If the name of the test suite and the name of some other
    package coincide (and have the same version), they will clobber
    each other.  In GHC 7.8 and earlier, this just flat out
    kills the build, because it will shadow.  There's an explicit
    test to make sure test suites don't conflict with the package
    name, but you can get unlucky.

    2. The test suite library is built into the same directory
    as the main library, which means that if the test library
    implements the same module name as something in the main
    library it will clobber the interface file and badness
    will ensue.

This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.

In doing so, it also lays the groundwork for other types of
internal libraries, e.g. #269, as well as extra (invisible)
libraries which we may install.

For GHC 7.8 and earlier, we follow the reserved namespace
convention as per #3017.

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

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

I could not install pcre-light because cabal failed with:

  parsing output of pkg-config --modversion failed

The output of that command was simply "8.02", which cabal could not
parse into a Version because of the leading zero. With this patch,
"8.02" now parses as (Version [8,2] []).

Switch to the tar package, drop builtin code

Also lets us build with older bytestring that shipped with older ghc.

Instead of qualifying, in some cases I just added an extra
'hiding' pragma to squelch errors.  Common conflicts
(just grep for hiding):

    - Flag
        - Distribution.Simple.Compiler
        - Distribution.PackageDescription
        - Distribution.Simple.Setup
    - installedComponentId
        - Distribution.Package
        - Distribution.InstalledPackageInfo
    - doesFileExist
        - Distribution.PackageDescription.Check
    - instantiatedWith
        - I renamed the field in InstalledPackageInfo.  But
          it's probably going away with Backpack bits; I
          migth just excise it soon.
    - absoluteInstallDirs and substPathTemplate
        - Distribution.Simple.InstallDirs
        - Distribution.Simple.LocalBuildInfo

I fixed some shadowing errors by renaming local variables in some cases.
Common shadowings (we should perhaps consider not using these as
method/field names):

    - freeVars
    - components
    - noVersion
    - verbosity
    - get
    - description
    - name

Some data structures were moved around (IPIConvert and ABIHash)
to make it easier to handle import lists.

Some functions in Utils could be turned into reexports of standard
library functions.

No explicit imports were removed from non-Cabal imports.  These
imports help maintain warning cleanliness across versions of GHC,
so I don't recommend removing them.

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

The RepoContext encapsulates the list of repositories, as well as some
associated state. In particular, it also encapsulates the HttpTransport, which
will be initialized on demand and cached thereafter.  This is important for two
reasons:

* For the hackage-security integration: in order to be able to use cabal's own
  HttpTransport API for the secure repo, we need to have access to that
  transport when we initialize the repo, but as things stood that was not
  possible (cabal was initializing repos ahead of time but the transport on
  demand).

* For the integration with the nix-local-branch it is important that the Repo
  type remains Serializable. By passing RepoContext rather than a list of
  Repos, we can leave RepoSecure serializable and separately maintain a mapping
  from cabal's Repo type to hackage-security's (stateful) Repository type.

This is in preparation for the next commit (and will avoid circular
module dependencies).

Add support for request headers in getHttp. Merging since approved.

Improve separation of concerns: introduce readBuildTreeRefsFromCache. Merging since approved. 

Function `putHttpFile` already allowed for request headers; we just the same
thing in `getHttp` as is done in `putHttpFile`.

Fix #2645 - make cabal merge package preferences if more than one is specified

Some functions had been generalized more than they needed to.

and simplify listBuildTreeRefs. This is just a refactoring, no actual change in
functionality.

Two new extensions coming with GHC 8.0, fixes #3025.

No need to test functions that come from the tar lib now.

Also, correct the expected output for sandbox remove source. Previously
the results were expected to come out in reverse order, because the old
filterEntriesM performed the monad actions in reverse order. The new
code doesn't have that bug so the results come out in the correct order.

The current incarnation of the tar package originated as code inside
cabal-install. That external tar package is now quite mature, with more
features and is much faster. In particular the tar index features will
be very useful for cabal-install, which currently has to maintain its
own custom-format index/cache.

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>

This reverts commit f907f1a6.
This commit caused a regression in Docker, see
https://ghc.haskell.org/trac/ghc/ticket/11326