This project is mirrored from Pull mirroring updated .
  1. 07 Mar, 2017 5 commits
    • Duncan Coutts's avatar
      Simplify IntegrationTests2 using overloaded strings · 1c46df4a
      Duncan Coutts authored
      We now have IsString instances for ModuleName, PackageName,
      UnqualifiedComponentName. We also have a local instance for PackageId.
      Using these makes the test case code shorter and clearer.
    • Duncan Coutts's avatar
      Split TargetSelectorNoTargets case into two sub-cases · 5dd6a76f
      Duncan Coutts authored
      In resolveTargetSelectors we return [TargetSelectorProblem] which
      includes a case TargetSelectorNoTargets. We split this into two cases:
      TargetSelectorNoTargetsInCwd and TargetSelectorNoTargetsInProject.
      The latter covers the important special case when there are no targets
      in the project as a whole. The former covers the same remaining cases as
      the original.
      This is a useful special case since it corresponds to running commands
      in a directory where there is no .cabal files and that is not underneath
      a project. Add a hopefully useful error message for this case.
      Also adjust the integration tests covering this case, which now split
      into two separate cases.
    • Duncan Coutts's avatar
      Add a number of TargetSelector tests · eb4783d4
      Duncan Coutts authored
      We already had tests covering valid syntax. This adds tests for invalid
      syntax and ambigious cases. Also cases for empty projects, or when there
      is no cwd package.
    • Duncan Coutts's avatar
      Change TargetSelector to remove TargetCwdPackage · 34e0d5cd
      Duncan Coutts authored
      Refactor so that instead of two constructors TargetPackage and
      TargetCwdPackage we have just TargetPackage with an extra bool-like field to
      distinguish the two.
      This simplifies things in the consumers of TargetSelector which
      typically have to treat TargetPackage and TargetCwdPackage in the same
      Also eliminate the list field in TargetCwdPackage. We don't yet support
      multiple .cabal files in one dir, and when we do we'll do the same for
      the cwd targets as for other explicit targets. The only annoying thing
      here is that we need to use a dummy package info value because the
      representation does not allow for not having one. The tradeoff is still
      worth it in terms of less verbose consumers.
      Also adjust tests.
    • Duncan Coutts's avatar
      Add positive tests for reading target selectors · ac006b4d
      Duncan Coutts authored
      So this covers most cases that are expected to work. Still need to do
      cases that are invalid syntax, unrecognised, or ambigious.
      Also added a note about a bit of an inconsistency in how we treat source
      file targets.
  2. 27 Feb, 2017 3 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.
    • Duncan Coutts's avatar
  3. 17 Jan, 2017 1 commit
  4. 27 Nov, 2016 2 commits
  5. 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 <>
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 04 Sep, 2016 2 commits
  11. 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 <>
  12. 10 Aug, 2016 2 commits
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 15 May, 2016 1 commit
  18. 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.