This project is mirrored from Pull mirroring updated .
  1. 21 May, 2008 1 commit
  2. 16 May, 2008 1 commit
  3. 12 May, 2008 1 commit
  4. 10 May, 2008 5 commits
  5. 09 May, 2008 6 commits
  6. 08 May, 2008 1 commit
    • Duncan Coutts's avatar
      Restructure the package installing code · 111e9bd0
      Duncan Coutts authored
      Previously each layer called the next layer down and therefore the
      top layer had to take all of the params that the bottom layer needed
      even though they were mostly or wholly unmodified on the way down.
      Now each layer takes the next layer as a parameter so we do not need
      to take the params that are not used directly by the current layer.
      The overall stack is then built by applying each layer to the next.
  7. 07 May, 2008 10 commits
  8. 06 May, 2008 3 commits
  9. 05 May, 2008 2 commits
    • Duncan Coutts's avatar
      Switch from DepGraph to InstallPlan · 5d8d0d74
      Duncan Coutts authored
      The dependency resolver has had to be extended in a slightly hacky
      way to gather the extra information needed by an install plan. In
      particular it requires the flags to use to configure each package,
      the actual versions of dependencies to use and all of the
      installed packages and their closure of dependencies.
      However the current resolver is fairly naive and so can be easily
      persuaded into producing an invalid install plan, in which case
      you'll get a detailed list of reasons as to why it is invalid.
    • Duncan Coutts's avatar
  10. 04 May, 2008 4 commits
  11. 01 May, 2008 1 commit
  12. 30 Apr, 2008 5 commits
    • Duncan Coutts's avatar
      Remove the resolveDependenciesLocal, implement it via resolveDependencies · bbd4fca1
      Duncan Coutts authored
      The local variant was for the case that we were starting from a package
      description rather than a dependency to a named package. In the local
      case we not only need to resolve the dependencies of the package but also
      to find a flag assignment for the local package. This case crops up in
      the resolver normally when we try to satisfy a dependency, we have to
      pick a flag assignment for the dependency and resolve its dependencies.
      It is annoying to have both entry points, especially as we want the
      resolver to be plugable. So instead we define the local package as an
      available package, then by resolving a single dependency on exactly the
      name and version of the local package then we can get an install plan for
      the local package. It also requires generalising installPkg to deal with
      the local case.
    • Duncan Coutts's avatar
      Generalise and rename PkgInfo to include local packages · 55beae12
      Duncan Coutts authored
      Renamed to AvailablePackage since that what it is really.
      Now instead of just representing packages from a remote hackage repo
      it includes an alternative for a local unpacked package. In future
      we should add more alternatives, eg for other local packages (ie not
      just the one that's unpacked in the current dir) and for remote
      packages in source control like darcs, git etc.
    • Duncan Coutts's avatar
      Convert the Install module to use the new SetupWrapper · a290d516
      Duncan Coutts authored
      And refactor slightly to batch some of the misc parameters
      together in a record rather than passing them all separately.
    • Duncan Coutts's avatar
      Add a new --cabal-lib-version flag to the install command · c0815a55
      Duncan Coutts authored
      It's used to select which version of the Cabal lib to use when
      configuring, building and installing packages. It's mainly so that
      we can use cabal-install to help us test that packages build ok with
      both old and new versions of the Cabal library. In particular we'd
      like to check every package on hackage to make sure that new Cabal
      versions are not breaking packages that worked with older versions.
    • Duncan Coutts's avatar