This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 01 Apr, 2017 1 commit
    • Duncan Coutts's avatar
      Create package DBs in building phase not planning phase · 83a42061
      Duncan Coutts authored
      Adjust things so that instead of creating the store package db during
      planning, we instead create them at the beginning of the building phase
      along with the other package dbs we create at that point. That is,
      create it in a write operation rather than in what is morally a read
      operation.
      
      Originally we had to do it in the planning phase because we used to read
      the compiler package db to see what was installed, whereas now we just
      use the store dir listing.
      
      In fact we were already creating some package dbs during the building
      phase, just not all of them, so this cleans things up in that respect.
      83a42061
  2. 24 Mar, 2017 5 commits
  3. 22 Mar, 2017 1 commit
    • Duncan Coutts's avatar
      Simplify HcPkg.register interface · f3c43333
      Duncan Coutts authored
      Remove the variants reregister and registerMultiInstance and generalise
      the main register variant to cover them all. Introduce a RegisterOptions
      record for the variations.
      
      Eliminate an unused form where we supply a file rather than an
      InstalledPackageInfo value.
      
      The motivation is so we can more easily add yet more variations shortly.
      
      This is an API change.
      f3c43333
  4. 21 Mar, 2017 3 commits
  5. 20 Mar, 2017 3 commits
  6. 17 Mar, 2017 16 commits
  7. 16 Mar, 2017 1 commit
  8. 15 Mar, 2017 1 commit
    • kristenk's avatar
      Use a more common type of conflict in the solver basic memory usage test. · ada7f93f
      kristenk authored
      The test previously caused the solver to backtrack because of a missing package.
      Missing packages are handled as a special case in the solver, so the test didn't
      exercise as much code as it could have.  This commit causes the solver to
      backtrack with a version conflict, which is a more common type of failure.
      Other tests continue to test the missing package case.
      ada7f93f
  9. 13 Mar, 2017 2 commits
  10. 12 Mar, 2017 3 commits
  11. 11 Mar, 2017 2 commits
  12. 10 Mar, 2017 2 commits
    • Edward Z. Yang's avatar
      Merge pull request #4386 from ezyang/pr/install-plan-refactor · 40318a77
      Edward Z. Yang authored
      ProjectPlanning refactor
      40318a77
    • Edward Z. Yang's avatar
      Refactor ProjectPlanning. · 9752f287
      Edward Z. Yang authored
      * toConfiguredComponents and friends are now monadic.  This means
        we can report a user-friendly error when we fail to find a
        dependency in the dependency map.  I had to rejigger a bit
        of the logic in ProjectPlanning since we were knot-tying through
        this function, but it all worked out.  This means
        that unbuildable_external_lib_deps is no more.
      
      * cc_internal_build_tools is no more; instead it's cc_exe_deps,
        which tracks ALL dependencies.  It also comes with a PackageId
        so we can build ConfiguredId cabal-install side.  This change
        propagates all the way to 'ReadyComponent'
      
      * ProjectPlanning: Instead of recomputing dependencies from scratch,
        we instead use the ElaboratedConfiguredPackages we just finished
        making to build the ComponentDeps.
      
      * ProjectPlanning now constructs a skeletal setupComponent.  This
        is used to setup the above with correct setup dependencies.
        In principle this component might also be used for building, but
        lots of functionality isn't written in yet.
      
      * filterExeMapDep is no more; it's all handled by Cabal now.
      
      * The ConfiguredComponentMap now handles both libraries and
        executables in one data structure.  This is nice.
      
      * compSetupDependencies is no more, because elaborated components
        never have custom setup.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      9752f287