This project is mirrored from Pull mirroring updated .
  1. 27 Feb, 2017 2 commits
    • 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.
    • Duncan Coutts's avatar
  2. 17 Jan, 2017 1 commit
  3. 27 Nov, 2016 2 commits
  4. 06 Oct, 2016 1 commit
    • 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 <>
  5. 29 Sep, 2016 1 commit
    • 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.
  6. 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.
  7. 27 Sep, 2016 1 commit
    • 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.
  8. 18 Sep, 2016 1 commit
    • Brendan Hay's avatar
      Track project configuration provenance · c2ebd714
      Brendan Hay authored
      - Excludes provenance from all roundtrip tests
      - Inserting explicit provenance when read from file
      - Special cases for bad package errors arising from
        implicit project configuration
  9. 04 Sep, 2016 2 commits
  10. 21 Aug, 2016 2 commits
    • Edward Z. Yang's avatar
      Rewrite ElaboratedConfiguredPackage. · c41ead76
      Edward Z. Yang authored
      As requested by Duncan, the majority of fields that originally
      lived in ElaboratedPackage now are moved to ElaboratedConfiguredPackage
      under the prefix 'elab'.  Some code has gotten simpler as a result.
      Signed-off-by: default avatarEdward Z. Yang <>
    • 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 <>
  11. 10 Aug, 2016 2 commits
  12. 25 Jul, 2016 1 commit
    • 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
      The equivalent change for the old build code path will be more
      disruptive since it does a lot of stuff with the execution results.
  13. 25 Jun, 2016 1 commit
    • Duncan Coutts's avatar
      Change rebuildInstallPlan to return pre-improvement plan · 3d4d48ce
      Duncan Coutts authored
      It takes a solver plan, makes an "elaborated plan" with nix style hashes
      but still of mostly source package and then does an improvement phase to
      make a plan with pre-existing packages from the store.
      Previously it only returned the improved plan, but for some things it's
      also useful to see the original elaborated plan with the source
      packages. In partciular it will be useful for plan.json status output.
      It will also be needed for the freeze command to be able to get at the
      flag choices, since this info is not preserved in installed packages.
  14. 03 Jun, 2016 1 commit
    • Duncan Coutts's avatar
      Add a test of the --keep-going feature · e1e6e123
      Duncan Coutts authored
      This actually only tests the new-build side of things, but the code in
      both cases is essentially identical. It also only tests the serial
      JobControl not the parallel JobControl. It may be sensible to have a
      specific unit test for the two JobControl implementations.
  15. 27 May, 2016 1 commit
    • Duncan Coutts's avatar
      Add integration tests for setup script handling · 02464abe
      Duncan Coutts authored
      Covers 3 of the 4 possible cases:
      1. explicit custom setup deps
      2. custom setup with implicit/default deps
      4. non-custom setup using the internal cabal lib version
      case 3 is a non-custom setup but where we're forced to use an external
      cabal lib version. This case is hard to test since it only happens when
      it's a newer (not older) Cabal lib version that the package requires,
      e.g. a .cabal file that specifies cabal-version: >= 2.0.
      Also, add a --with-ghc option to the integration test suite, which lets us
      more easily test with different ghc versions.
      Also, don't use parallel builds in any of the integration tests, as the
      self-exec method will not work, and some tests need to install deps for
      some ghc versions.
  16. 15 May, 2016 1 commit
  17. 14 May, 2016 1 commit
    • Duncan Coutts's avatar
      Add new integration tests, initially covering build exceptions · 40846f06
      Duncan Coutts authored
      These integration tests, unlike the existing ones, don't call cabal as
      an external processes. Instead they use the cabal code directly. This
      makes it possible to conveniently test catching exceptions.
      Add a couple tests for exceptions in finding projects. There should be a
      lot more for the various phases of planning.
      Also add a couple tests for exceptions in the configure and build
      phases. These test the previous patch that improves the exception
      handling so that failures are added into the residual plan rather than
      just propagating immediately.