This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 25 Jul, 2016 10 commits
    • Duncan Coutts's avatar
      Remove the now unused PlanPackage states · 7cb0844b
      Duncan Coutts authored
      We now just have the initial states, PreExisting and Configured. The
      Processing, Installed and Failed states are gone. We now do traversals
      separately from the InstallPlan, so we no longer need these states.
      7cb0844b
    • Duncan Coutts's avatar
      Rename the new InstallPlan.{ready,completed,failed} · 86853416
      Duncan Coutts authored
      Rename from prime' versions to the normal names, now that the old ones
      have been removed.
      86853416
    • Duncan Coutts's avatar
      Remove the old InstallPlan.ready · f28cf318
      Duncan Coutts authored
      There were two uses other than excuteInstallPlan. The new ready impl can
      be used in both these cases, allowing the old one to be removed.
      f28cf318
    • Duncan Coutts's avatar
      Remove a number of now-unused InstallPlan operations · 713af703
      Duncan Coutts authored
      These were the primitives used by executeInstallPlan to change the
      package states to Processing, Installed, Failed etc.
      
      The 'ready' is still used in a couple other places, so those need to be
      modified before the old 'ready' can be removed.
      713af703
    • Duncan Coutts's avatar
      Convert the old install code to use InstallPlan.execute · 448714b8
      Duncan Coutts authored
      Redefine the local executeInstallPlan util in terms of
      InstallPlan.execute. Of course now executeInstallPlan returns
      BuildResults instead of an upated InstallPlan. This requires changes in
      all the code that looks at the result of the build execution, including
      console error reporting, build reports, symlinks etc.
      448714b8
    • Duncan Coutts's avatar
      Convert new-build to use InstallPlan.execute · 97cff5c0
      Duncan Coutts authored
      Eliminate the local executeInstallPlan. The main change is that the new
      execute returns BuildResults instead of an upated InstallPlan. This has
      a few knock-on conseuqnces for the code that looks at the result of the
      build execution.
      
      Currently we don't actually do that much with the results in the
      new-build code path (though we should) so there's less disruption than
      one might imagine. The biggest change is in the integration tests which
      do inspect the execution result to check things worked or didn't work as
      expected.
      
      The equivalent change for the old build code path will be more
      disruptive since it does a lot of stuff with the execution results.
      97cff5c0
    • Duncan Coutts's avatar
      Add InstallPlan.execute plus tests · 31be24fa
      Duncan Coutts authored
      This is intended to replace a couple existing executeInstallPlan
      implementations.
      
      The tests check that execute visits packages in reverse topological
      order, for both serial and parallel job control. There's also a check
      that serial execute and executionOrder use exactly the same order.
      31be24fa
    • Duncan Coutts's avatar
      Replace linearizeInstallPlan utils by InstallPlan.executionOrder · af112a61
      Duncan Coutts authored
      Delete two different ugly versions of linearizeInstallPlan. Yay.
      af112a61
    • Duncan Coutts's avatar
      Add InstallPlan.executionOrder · 2d6f94ea
      Duncan Coutts authored
      This is a replacement for the existing linearizeInstallPlan utils.
      It uses the new separate traversal approach.
      2d6f94ea
    • Duncan Coutts's avatar
      Add new InstallPlan traversal primitives · 4d09392f
      Duncan Coutts authored
      Currently the way to traverse/execute an InstallPlan involves using the
      InstallPlan itself as the processing state.
      
      This adds a new Processing type and associated operations to help write
      InstallPlan traversals that are separate from the InstallPlan itself.
      4d09392f
  2. 24 Jul, 2016 2 commits
    • Edward Z. Yang's avatar
      Implement --cabal-file, allows multiple Cabal files in directory · e507ca84
      Edward Z. Yang authored
      
      
      This is primarily intended for use with the Cabal test suite (allowing
      us to easily specify multiple Cabal packages for the same Haskell source
      files), but maybe some end-users will find it useful as well.  If there
      are multiple Cabal files in the current working directory, --cabal-file
      (for configure) allows you to disambiguate which one to build with.
      
      There's a big hack to handle the BOM check, as it is inconvenient to
      plumb the flag value all the way to the check code.  Some bigger
      refactoring needed, see #3552.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e507ca84
    • Edward Z. Yang's avatar
      As much as possible, expunge uses of localPkgDescr. · e3c64e6d
      Edward Z. Yang authored
      
      
      The big change here is that most of the functions in
      Distribution.Types.HookedBuildInfo have to take a
      PackageDescription explicitly.  I hate the new type,
      so I primed these new functions, and added functions
      which use 'localPkgDescr'.  Presently those have WARNINGs
      attached to them so people don't accidentally use them;
      once we fix 'HookedBuildInfo' we can change this.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e3c64e6d
  3. 23 Jul, 2016 4 commits
  4. 22 Jul, 2016 2 commits
  5. 21 Jul, 2016 2 commits
  6. 19 Jul, 2016 11 commits
  7. 11 Jul, 2016 3 commits
  8. 10 Jul, 2016 1 commit
  9. 03 Jul, 2016 1 commit
  10. 02 Jul, 2016 1 commit
  11. 27 Jun, 2016 1 commit
  12. 26 Jun, 2016 1 commit
    • Duncan Coutts's avatar
      Don't initialise package dbs concurrently · 5adaf585
      Duncan Coutts authored
      Instead initialise all the ones we'll need in advance of building any
      packages. The alternative would have been to use a lock, but there's no
      particular advantage in trying to delay initialisation and avoiding
      locks keeps things simpler.
      
      This should fix #3460
      
      Another similar issue was fixed by 1acc00f8 which serialised the
      registration of packages in the local inplace package db, avoiding
      lost updates (which could previously be observed in test case T3460).
      5adaf585
  13. 25 Jun, 2016 1 commit