This project is mirrored from Pull mirroring updated .
  1. 20 Jul, 2020 1 commit
  2. 18 May, 2020 1 commit
    • Oleg Grenrus's avatar
      Make cabal-install compilable with NoImplicitPrelude · d4fd273b
      Oleg Grenrus authored
      I.e. find out where we don't yet
      used `Distribution.Client.Compat.Prelude`.
      - If the module is small I added direct `Prelude` imports.
      - Add Exception, deepseq stuff to Cabal Prelude
      - Add Parsec, Pretty and Verbosity to Client Prelude
      - use for, for_, traverse and traverse_ (removes need for Control.Monad)
  3. 13 May, 2020 1 commit
  4. 20 Dec, 2019 1 commit
  5. 01 Dec, 2018 2 commits
  6. 28 Nov, 2018 1 commit
    • Oleg Grenrus's avatar
      Move ReadP out of Cabal (to cabal-install) · baf78ca2
      Oleg Grenrus authored
      - Distribution.Compat.ReadP to Distribution.Deprecated.ReadP
      - Distribution.Text to Distribution.Deprecated.Text
      - all Text instances needed by cabal-install to Deprecated.Text too
      - Distribution.ParseUtils to Distribution.Deprecated.ParseUtils
      - Remove deprecated Distribution.PrettyUtils
      - new Distribution.Text with
          display = prettyShow
          simpleParse = simpleParsec
        to not break too much stuff (Custom Setup.hs)
      - parseInstalledPackageInfo type signature changed to use
        `base` types
      This removes around 2k lines from Cabal the library.
      git diff --stat shows less, as files are moved (git is smart).
      Even so, total 300 lines removal at this point.
  7. 06 Nov, 2018 3 commits
  8. 03 Nov, 2018 1 commit
  9. 14 Jul, 2018 1 commit
  10. 25 Jun, 2018 2 commits
  11. 11 Dec, 2017 1 commit
  12. 18 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Differentiate letter for the dist-dir layout of components · e2a52dee
      Herbert Valerio Riedel authored
      This has been a pet-peeve of mine since 1.24 but I forgot to address
      this in time for the 2.0 release, as it conflates all the component
      kinds into an opaque single "c" namespace thereby losing information,
      rather than encoding the component type in a more expressive single
      letter path component.
  13. 02 Aug, 2017 1 commit
  14. 01 Apr, 2017 1 commit
    • 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.
  15. 24 Mar, 2017 1 commit
    • Duncan Coutts's avatar
      Refactor: split StoreDirLayout out of CabalDirLayout · 045c7c9a
      Duncan Coutts authored
      So we have a spec of the layout of the store, independent of the
      instance of the store within ~/.cabal/store. This will make new store
      handling code cleaner by not entangling it with other global ~/.cabal
      We may also in future want to allow global and per-user stores, and we
      certainly want the ability to specify a store location outside of
      ~/.cabal (though this could be done with the existing code too).
  16. 07 Mar, 2017 1 commit
    • Duncan Coutts's avatar
      Adjust rel/abs path semantics in defaultDistDirLayout · af96c089
      Duncan Coutts authored
      In the ProjectRootExplicit case, findProjectRoot actually returns an
      absolute directory but a project file name that is relative to that.
      This seems to be the sensible thing to do, so we change what ProjectRoot
      is declared to be to match this, and adjust defaultDistDirLayout
      This only makes a difference when a custom relative project file is
  17. 27 Feb, 2017 2 commits
    • Duncan Coutts's avatar
      elaborate impl of findProjectRoot · 5b1eca08
      Duncan Coutts authored
      Take an extra arg to control where to start searching, not just process
      current directory. This is mainly to make it easier to test without
      having to mutate the cwd but is potentially useful generally for
      Return more detailed info: not just the directory but return if it's an
      implicit or an explict project root with a cabal.project file. In the
      latter case also return the cabal.project file since its name can be
      overridden. Then also adjust defaultDistDirLayout to take this more
      detailed ProjectRoot type, thus avoiding having to duplicate the logic
      about the location of the cabal.project file.
      Change the behaviour so that if an explicit cabal.project file name is
      given and it is not found then fail, rather than falling back to an
      implicit project root style. This would seem to make most sense: if the
      user specifies an explict cabal.project file then it'd be odd if we
      silently ignore that if the user misspells it or something. The implicit
      root default is really for the really simple case, not when users are
      explicitly specifying stuff.
      Also add a couple simple tests for findProjectRoot.
    • Duncan Coutts's avatar
      Extend DistDirLayout with project root and cabal.project · 2b26e75b
      Duncan Coutts authored
      So the DistDirLayout now contains the root dir of the project as a
      whole, which eliminates the need to pass it separately in several cases.
      It also contains the location of the cabal.project file, which again
      avoids having to pass it around.
      In part these changes were to allow the elimination of uses of the
      legacy config types in the new-build code. The idea is that the legacy
      config types are only used by conversion into the new config types, and
      then only the new types are used in the new code.
  18. 27 Nov, 2016 1 commit
  19. 31 Oct, 2016 1 commit
  20. 08 Oct, 2016 1 commit
  21. 06 Oct, 2016 1 commit
    • Edward Z. Yang's avatar
      Introduce the new representation of UnitId · d7bd9078
      Edward Z. Yang authored
      'SimpleUnitId' constructor renamed to 'UnitId', and augmented
      with a new field 'Maybe String' recording a hash that uniquely
      identifies an instantiated unit of the library 'ComponentId'.
      'UnitId' can't be used to represent partially instantiated
      unit identifiers; see Distribution.Backpack for how we handle that.
      Previous uses of 'SimpleUnitId' should now use 'newSimpleUnitId'.
      'unitIdComponentId' folded into a record selector for 'ComponentId'.
  22. 06 Sep, 2016 1 commit
  23. 02 Sep, 2016 1 commit
  24. 21 Aug, 2016 1 commit
    • Edward Z. Yang's avatar
      Per-component new-build support (no Custom support yet). · d9bf6788
      Edward Z. Yang authored
      A bit of a megapatch.  Here's what's in it:
      * First, a few miscellaneous utility functions and reexports
        in Cabal.  I could have split these into a separate commit
        but I was too lazy to.
      * Distribution.Client.Install got refactored:
        instead of using PackageFixedDeps, it uses IsUnit
        instead.  This is because we weren't using ComponentDeps
        in a nontrivial way; we just need some graph structure
        and IsNode (with UnitId keys) fulfills that. I also removed the
        invariant checking and error reporting because it was
        being annoying (we check the invariants already in
      * Look at Distribution.Client.ProjectPlanning.Types.
        This contains the primary type change: ElaboratedConfiguredPackage
        is now EITHER a monolithic ElaboratedPackage, or a per-component
        ElaboratedComponent (it should get renamed but I didn't do that
        in this patch.)  These are what we're going to store in our
        plans: if a package we're building has a Setup script which supports
        per-component builds, we'll explode it into a component.  Otherwise
        we'll keep it as a package.  We'll see codepaths for both
      * OK, so the expansion happens in ProjectPlanning, mostly in
        'elaborateAndExpandSolverPackage'.  You should review the
        package hash computation code closely.  When we can separate
        components, we compute a hash for each INDEPENDENTLY.  This
        is good: we get more sharing.
      * We need to adjust the target resolution and pruning code
        in ProjectOrchestration and ProjectPlanning.  I did a dumb
        but easy idea: if a user mentions 'packagename' in a
        target name, I spray the PackageTarget on every
        possibly relevant IPID in buildTargets', and then pare
        it down later.
      * And of course there's code in ProjectBuilding to actual
        do a configure and then build.
      * We change the layout of build directories so that we can
        track each component separately.  While I was doing that,
        I also added compiler and platform information.
      Custom doesn't work yet because I need to give them their own
      separate component, and teach Cabal how to build them specially.
      Signed-off-by: default avatarEdward Z. Yang <>
  25. 17 Mar, 2016 1 commit
    • Duncan Coutts's avatar
      Add new DistDirLayout module · fe3596b9
      Duncan Coutts authored
      This describes in one place the layout of the new dist dir, as used by
      the nix-local-build branch. Also a similar approach to describing the
      layout of the user-wide cabal directory.
      The idea is that this centralises the description and makes it easier
      to change and handle systematically (e.g. we have problems currently
      with some user-wide files not being reolocatable).
      (cherry picked from commit 7907a55c)