This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 19 Dec, 2017 2 commits
  2. 02 Dec, 2017 1 commit
  3. 03 Nov, 2017 1 commit
  4. 26 Oct, 2017 3 commits
  5. 22 Oct, 2017 1 commit
    • Moritz Angermann's avatar
      Adds `new-update` · b3af0bab
      Moritz Angermann authored
      new-update uses the new-style logic to update the repositories.  As such it
      respects `repository` fields in the `cabal.project(.local)` file and updates
      them as well.  This is essential when working with hackage overlays, where
      the overlay repositories are specified as `repository` fields in the
      `cabal.project(.local)` file.
      b3af0bab
  6. 14 Oct, 2017 1 commit
    • Francesco Gazzetta's avatar
      Add a new-install command · 9c62e122
      Francesco Gazzetta authored
      Add the first part of the new-install command: nonlocal exes.
      
      See #4558 for the design concept.
      
      This part of the command installs executables from outside of a project
      (ie from hackage) in the store and then symlinks them in the cabal bin
      directory.
      
      This is done by creating a dummy project and adding the targets as extra
      packages.
      9c62e122
  7. 03 Oct, 2017 1 commit
  8. 15 Aug, 2017 1 commit
    • Oleg Grenrus's avatar
      Use parsec, drop parsec flag · 5e4f4d58
      Oleg Grenrus authored
      - Manually generate Lexer.hs
      - Temporarily disable parser-hackage-tests on appveyor (needs
        01-index.tar)
      - Add root Makefile to handle commmon dev tasks (genering Lexer.hs)
      5e4f4d58
  9. 25 Jul, 2017 2 commits
  10. 20 Jun, 2017 1 commit
    • bardur.arantsson's avatar
      Create separate compat-prelude for solver · 34233d76
      bardur.arantsson authored
      The idea here is to break the dependency that has crept in from the
      "Solver" into the "Client". (If there's ever going to be a separate
      solver then the dependency would become a big problem.)
      34233d76
  11. 18 Jun, 2017 1 commit
  12. 23 May, 2017 3 commits
  13. 18 May, 2017 1 commit
  14. 07 May, 2017 2 commits
  15. 27 Apr, 2017 1 commit
  16. 21 Apr, 2017 1 commit
  17. 01 Apr, 2017 3 commits
    • Duncan Coutts's avatar
      Add unit tests for the new store code · 0a3c9623
      Duncan Coutts authored
      Sadly we cannot do proper parallel tests within a single process
      becuase our fancy inter-process file locking code is thrwarted by the
      stricter normal intra-process file locking.
      0a3c9623
    • Duncan Coutts's avatar
      New module for store handling, with concurrent updates · b05b9ae7
      Duncan Coutts authored
      A new module with utilities for managing the store. This includes a new
      approach for store updates that allows for concurrent updates to the
      store from different processes.
      
      This relies on the new file locking code. We log a message if we wait
      for a store file lock. This should be a rare occurrence in practice,
      but would help debugging if some other zombie process was holding the
      file lock.
      b05b9ae7
    • kristenk's avatar
      Replace a use of PSQ with []. · bf551a7d
      kristenk authored
      This change will make it easier to replace PSQ with WeightedPSQ in solver
      GoalChoice nodes.
      bf551a7d
  18. 24 Mar, 2017 1 commit
    • Duncan Coutts's avatar
      Add new compat code for OS file locking · c1562d55
      Duncan Coutts authored
      This code is backported from base from ghc-8.2.
      
      It will be used as part of the concurrent store updates. It may also be
      used in future to work around the lack of file locking in ghc-pkg prior
      to version 8.2.
      c1562d55
  19. 17 Mar, 2017 1 commit
    • Edward Z. Yang's avatar
      Refactor MungedPackageId and PackageIndex. · f4ded04f
      Edward Z. Yang authored
      
      
      This makes the necessary changes to 4dc0f30fc36914ee2f01bde016bee98b8e0bb0bb
      to handle component configuring correctly.  It probably is a good step
      towards pkg:lib style dependencies.
      
      The big ideas:
      
      * There's a new AnnotatedId type, which is any identifier (like
        ComponentId), but also with a PackageId and ComponentName.
        It's a bit like ConfiguredId, but ConfiguredId is specialized
        for ComponentId.  There's a conversion function
        annotatedIdToConfiguredId.
      
      * We adopt a totally new strategy for handling MungedPackageId in
        InstalledPackageInfo.  Rather than store the munged package
        identifier in IPI, we NEVER store it, instead computing it
        from the package name and library name (which are stored.)
        There is now code to PARSE a munged package name into these
        two components, so that when we read 'name' we get the
        correct info.  The resulting code is splendidly clear.
      
      * Some places where we took a ComponentName (notably
        computeCompatPackageName) we now take 'Maybe UnqualComponentName'.
        This is more accurate, because compatibility package names are
        only computed for libraries, not other components.  Some code
        in Distribution.Backpack.ReadyComponent is partial now,
        but the invariants should hold up.
      
      * A number of places where MungedId was applied, I undid them.
        Most notable are macro generation (that should be PACKAGES,
        not components) and mkLegacyUnitId (since REALLY old style
        unit identifiers, we won't support internal libraries anyway.)
      
      * Many functions in PackageIndex are monomorphized to
        InstalledPackageInfo.  Fortunately cabal-install's usage
        still works.
      
      * Distribution/Client/SolverPlanIndex.hs, not used by anyone,
        got the axe.
      
      * Dependency solving has a hack to solve the problem of how to
        interpret installed internal libraries in the package database.
        The basic idea is that, although in most cases where we used
        a MungedId, we say it explicitly, in the SOLVER, we munge
        *installed package names* only, and keep the type PackageName.
        It's a hack, but the alternative is to write a lot more code.
        Note that is MORALLY PN is indeed a PackageName, since we really
        are solving for honest to goodness packages, not components!
        See Note [Index conversion with internal libraries] for more
        details.
      
      * ConfiguredId now records the ComponentName.  This is quite important,
        because we need to use it to figure out how we are going to phrase
        --dependency.  In fact, it is a miracle that this worked at all
        (and it only worked because of a very skeevy update to the PackageId
        in the creation of ConfiguredComponent).  Irritatingly, this must
        be a Maybe ComponentName, because a ConfiguredId MIGHT refer to
        a setup component. Very distressing.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      f4ded04f
  20. 10 Mar, 2017 1 commit
  21. 07 Mar, 2017 11 commits