This project is mirrored from Pull mirroring updated .
  1. 08 Oct, 2016 1 commit
  2. 06 Oct, 2016 12 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Add a new 'DefUnitId' type with invariant. · bd3040bd
      Edward Z. Yang authored
      The DefUnitId invariant says that the UnitId in a DefUnitId
      must in fact be a definite package (either with no holes, or
      fully instantiated.)  This is in constrast to a UnitId,
      which can also identify an indefinite unit identifier.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Rename IndefModule to OpenModule. · 2e42ca27
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Rename IndefUnitId to OpenUnitId. · 62ddf8e0
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      cabal-install changes for Backpack. · 69cfeec2
      Edward Z. Yang authored
      Here are the main changes:
          New utility function 'fromSolverInstallPlanWithProgress'
          which is a monadic version of 'fromSolverInstallPlan'.
          This is because, with Backpack, the conversion from
          'SolverInstallPlan' to 'InstallPlan' can fail/log.
          OK. A bunch of new information we need to track.
          New fields in 'ElaboratedConfiguredPackage':
              elabInstantiatedWith :: ModuleSubst (for --instantiated-with)
              elabLinkedInstantiatedWith :: IndefModuleSubst (intermediate)
              elabModuleShape :: ModuleShape (for mix-in linking)
          Here is how all the dependency functions relate to
          one another:
              elabOrderDependencies :: [UnitId]
                  Used for nodeNeighbors, this just specifies what needs
                  to be built before we build this module.  These refer
                  either to fully instantiated unit ids (hashed unit id)
                  or uninstantiated unit ids (effectively component id)
                  but never a partially instantiated unit id, since we
                  never have an install item in our plan for a partially
                  instantiated package.
                  These dependencies are factored into two parts:
                  which soley are used to determine if we need to enable
                  executables/libraries of a package we are building
                  (this isn't new)
              elabLibDependencies :: [ComponentId]
                  These are the things we pass to Setup using the --dependency
                  flag; so they are JUST ComponentId, not a full on UnitId.
                  The mix-in linking process in Setup will reconstruct the
                  necessary UnitId.
              elabExeDependencies :: [ComponentId]
                  These are the things that we must add to the PATH to run.
                  At the moment, this coincides with elabOrderExeDependencies.
          For components, there is also:
              compLinkedLibDependencies :: [IndefUnitId],
                  The partially instantiated unit ids that GHC would be
                  invoked with, if we were invoking it directly.
                  This is used when we subsequently instantiate components.
              compNonSetupDependencies :: [UnitId]
                  Non-setup, ORDER dependencies; i.e., everything that has
                  to be built before us that is not a setup script.
          The workhorse.
          Essentially, we redo all of the steps from
          Distribution.Backpack.Configure, but in the context of planning an
          entire install plan.  The conversion from SolverInstallPlan
          to InstallPlan is responsible for mix-in linking
          (inside elaborateSolverToComponents); afterwards,
          instantiateInstallPlan is responsible for filling in
          the missing, instantiated packages which we need to compile.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Use the new Backpack code for the configure step · 688b31e3
      Edward Z. Yang authored
      Many of the configure functions were factored out and moved to the new
      Backpack modules. The new configure action makes a call to
      Distribution.Backpack.Configure to setup the ComponentLocalBuildInfo.
      Also add an @--instantiate-with@ flag to ./Setup configure, so that
      cabal-install can specify how it wants to instantiate a package that
      it is building.
      Also do the minimal necessary adjustments in cabal-install.
    • Edward Z. Yang's avatar
      Update GhcOptions to use IndefUnitId for -package-id · 5b378e48
      Edward Z. Yang authored
      We will use this when building indefinite libraries.
    • 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'.
    • Edward Z. Yang's avatar
    • Mikhail Glushenkov's avatar
      Fix CI on Mac OS X with GHC 7.8 and earlier. · 2ed454ee
      Mikhail Glushenkov authored
      On recent OS X, Cabal does not work correctly because it assumes
      that a permission denied error when reading permissions on
      executables, resulting in errors like "Setup: /usr/bin/ar: permission denied".
      The proximal fix for this is to add a constraint on unix when we build
      Cabal/cabal-install to avoid building with the buggy version of unix.
      But this causes other problems:
      - Bumping the version of unix means that our local build of Cabal
        will depend on things from the store.  But we weren't passing
        this to GHC when compiled Setup.hs for Cabal's package-tests.
        Set CABAL_PACKAGETESTS_DB_STACK env var explicitly to point
        to the right locations.
      - The new configuration of versions exposed some bugs in some
        macro expanded code in cabal-install; we qualified those
        imports to squash unused warnings.
      - The cabal-install integration-tests occasionally use Cabal from
        the system GHC.  Since this will never work on OS X, we just
        skip the tests in those cases.
      Signed-off-by: default avatarEdward Z. Yang <>
  3. 05 Oct, 2016 1 commit
  4. 04 Oct, 2016 2 commits
  5. 02 Oct, 2016 2 commits
  6. 30 Sep, 2016 1 commit
  7. 29 Sep, 2016 9 commits
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Split types out of ProjectBuilding to avoid cycles · 5f5d9598
      Duncan Coutts authored
      We're going to need ProjectPlanOutput to import the ProjectBuilding
      types, but this would cause a cycle with ProjectPlanning. So do the same
      thing we did with ProjectPlanning and move the types out.
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Move improveInstallPlanWithUpToDatePackages out of rebuildTargetsDryRun · f1c84021
      Duncan Coutts authored
      Instead rebuildTargetsDryRun will just return the BuildStatusMap and
      runProjectPreBuildPhase in ProjectOrchestration will compose things by
      calling improveInstallPlanWithUpToDatePackages.
      This is just a slight shifting of functionality from here to there, but
      better reflects responsibilities. This is also slightly with a future
      status command in mind which likely only needs the BuildStatusMap.
      Also adjust the tests after changing type of rebuildTargetsDryRun.
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Adjust behaviour of reportBuildFailures · 4d308c04
      Duncan Coutts authored
      Make sure it consistently uses stderr, rather than a mixture of stdout
      and stderr. Also rename it to dieOnBuildFailure to make it clear that
      it is fatal in the case of build failures.
      In general we report build failures in two steps: header plus build log
      for each failing package, then a final die exception with summary.
      Previously the build log step was reported to stdout whereas the die
      exception message gets reported to stderr. So we switch that to use
      new dieMsg and dieMsgNoWrap utils so that it all goes to stderr. Also,
      like die, these are reported irrespective of the verbosity.
      This is more or less just a workaround for the fact that we do not yet
      have a nice structured/formatted error mechanism that would allow us to
      throw just the one error in this case.
    • Duncan Coutts's avatar
      Make projectRootDir available for the post-build phase · 45a6d13a
      Duncan Coutts authored
      Stick it into the ProjectBuildContext. It's not used yet but it will be
      useful, in particular for updating the .ghc.environment file. Arguably
      it ought to just live in the DistDirLayout.
    • Duncan Coutts's avatar
      Add runProjectPostBuildPhase in project orchestration · 66cd8579
      Duncan Coutts authored
      Previously the post-build phase was just reportBuildFailures and was
      called directly from Cmd{Build,Repl}. So initially this just rearranges
      things without changing behaviour, but it gives us a place to add other
      post-build actions.
      This also simplifies the code in Cmd{Configure,Build,Repl}.
      A few examples are mentioned in a comment, including updating:
        bin symlinks/wrappers
        haddock/hoogle/ctags indexes
        delete stale lib registrations
        delete stale package dirs
    • Duncan Coutts's avatar
      Go back to the plan.json reflecting only env inputs · 602a5434
      Duncan Coutts authored
      In particular it will not reflect the status of the build, ie it will
      list all the source packages and their configuration but not say if
      they're already installed in the store.
      There's a slightly vauge principle at work here, that we should
      distinguish between build outputs and build ststus: build outputs
      should be (morally) pure functions of the environment, where as build
      status is about the degree to which the current cached outputs reflect
      the state of the inputs (ie are build outputs up to date or not).
      So in this case that means the plan.json is considered an output and
      thus it should not depend on the state of the store. We can certainly
      provide machine readable status info, but this should be a separate
  8. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      Finally, this also adds a new functor-like convenience function
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      for modifying the version number components.
  9. 27 Sep, 2016 2 commits
    • Arian van Putten's avatar
      Make interactive setup delegate CTRL+C · 005f6dfa
      Arian van Putten authored
      Fixes #3899
      When cabal new-repl spawns ghci, it spawns this as a subprocess.
      In UNIX like systems, if a CTRL+C is sent to this child process
      it also bubbles up to the parent process, causing it to terminate.
      Also see
      However, this is not what we want for interactive subprocesses.
      Interactive processes usually define their own handlers for CTRL+C,
      for example GHCi uses CTRL+C to reset the input buffer. So instead
      of terminating on CTRL+C we want to delegate CTRL+C to GHCi
      and let it do its thing.
      Luckily, we can enable CTRL+C delegation such that the parent
      process ignores the CTRL+C and instead delegates it to the
      child process.
    • Herbert Valerio Riedel's avatar
      Make `PackageName` type opaque (#3896) · dabd9d98
      Herbert Valerio Riedel authored
      When looking at heap-profiles of `cabal-install`, the `(:)` constructor
      stands out as the most-allocated constructor on the heap.
      Having to handle 10k+ package names contributes to the allocation
      numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
      per character footprint.
      This commit is a preparatory commit to pave the way for changing
      `PackageName`'s internal representation to something like
      `ShortByteString` (which is essentially a thin wrapper around primitive
      `ByteArray#`s which themselves have have an overhead of 2 words + one
      byte per ASCII character rounded up to nearest word) which would allow
      to reduce the memory footprint by a full order of magnitude, as well as
      reduce pointer chasing and GC overhead.
  10. 26 Sep, 2016 9 commits