This project is mirrored from Pull mirroring updated .
  1. 25 Jul, 2016 12 commits
    • Duncan Coutts's avatar
      Remove the now unused PlanPackage states · 7cb0844b
      Duncan Coutts authored
      We now just have the initial states, PreExisting and Configured. The
      Processing, Installed and Failed states are gone. We now do traversals
      separately from the InstallPlan, so we no longer need these states.
    • Duncan Coutts's avatar
      Rename the new InstallPlan.{ready,completed,failed} · 86853416
      Duncan Coutts authored
      Rename from prime' versions to the normal names, now that the old ones
      have been removed.
    • Duncan Coutts's avatar
      Remove the old InstallPlan.ready · f28cf318
      Duncan Coutts authored
      There were two uses other than excuteInstallPlan. The new ready impl can
      be used in both these cases, allowing the old one to be removed.
    • Duncan Coutts's avatar
      Remove a number of now-unused InstallPlan operations · 713af703
      Duncan Coutts authored
      These were the primitives used by executeInstallPlan to change the
      package states to Processing, Installed, Failed etc.
      The 'ready' is still used in a couple other places, so those need to be
      modified before the old 'ready' can be removed.
    • Duncan Coutts's avatar
      Convert the old install code to use InstallPlan.execute · 448714b8
      Duncan Coutts authored
      Redefine the local executeInstallPlan util in terms of
      InstallPlan.execute. Of course now executeInstallPlan returns
      BuildResults instead of an upated InstallPlan. This requires changes in
      all the code that looks at the result of the build execution, including
      console error reporting, build reports, symlinks etc.
    • 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.
    • Duncan Coutts's avatar
      Add InstallPlan.execute plus tests · 31be24fa
      Duncan Coutts authored
      This is intended to replace a couple existing executeInstallPlan
      The tests check that execute visits packages in reverse topological
      order, for both serial and parallel job control. There's also a check
      that serial execute and executionOrder use exactly the same order.
    • Duncan Coutts's avatar
      Replace linearizeInstallPlan utils by InstallPlan.executionOrder · af112a61
      Duncan Coutts authored
      Delete two different ugly versions of linearizeInstallPlan. Yay.
    • Duncan Coutts's avatar
      Add InstallPlan.executionOrder · 2d6f94ea
      Duncan Coutts authored
      This is a replacement for the existing linearizeInstallPlan utils.
      It uses the new separate traversal approach.
    • Duncan Coutts's avatar
      Add new InstallPlan traversal primitives · 4d09392f
      Duncan Coutts authored
      Currently the way to traverse/execute an InstallPlan involves using the
      InstallPlan itself as the processing state.
      This adds a new Processing type and associated operations to help write
      InstallPlan traversals that are separate from the InstallPlan itself.
    • Duncan Coutts's avatar
      Add a couple Graph operations, direct deps and reverse deps · 817d2b28
      Duncan Coutts authored
      Needed for some new InstallPlan functions
    • Duncan Coutts's avatar
      Add a test for an existing InstallPlan util · ba5297ec
      Duncan Coutts authored
      The main thing this adds is infrastructure for generating random
      InstallPlans (which is not totally trivial given their structure).
  2. 24 Jul, 2016 5 commits
  3. 23 Jul, 2016 14 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Refactor LocalBuildInfo interface. · d94ddc0e
      Edward Z. Yang authored
      This is an omnibus patch, with the overall goal of making
      LocalBuildInfo Great Again.  The essential ideas:
      * New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo'
        and 'Component'.  Eventually, it will also record file paths / module
        targets.  This data structure is basically what you want; a lot of
        old Cabal code did lots of gyrations converting from
        'ComponentLocalBuildInfo' to 'Component' and vice versa, now
        it's all centralized.
      * The "new" API for 'LocalBuildInfo' is in
        "Distribution.Types.LocalBuildInfo".  The general principle
        is, where we previous dealt in 'ComponentLocalBuildInfo',
        we now deal in 'TargetInfo'.  There are shockingly few
        functions we need!
      * I've restored 'componentsConfigs' to its Cabal 1.24 signature
        for BC.
      * I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo":
        'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
        'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
        'enabledComponents'.  For each I checked on Hackage that they were
        not used.
      * 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and
        'componentsInBuildOrder' are deprecated to encourage people
        to instead use the 'TargetInfo's to finger which components
        they want built.
      * 'ComponentLocalBuildInfo' now stores internally the computed
        'componentInternalDeps', so that 'LocalBuildInfo' can simply store
        a graph of 'ComponentLocalBuildInfo'.
      * The code in Configure has been streamlined to use our new Graph
        data type to great success.
      * The type of 'runTest' changed to take a 'ComponentLocalBuildInfo',
        bringing it more in line with everything else.
      * New function 'readTargetInfos' which combines 'readBuildTargets'
        and 'checkBuildTargets', which is what you really wanted anyway.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Merge pull request #3607 from ezyang/pr/autogen · 6305156f
      Edward Z. Yang authored
      Restore autogenModulesDir to BC-compatible signature
    • Edward Z. Yang's avatar
      Restore 'autogenModulesDir' in deprecated form. · ff6aa2f0
      Edward Z. Yang authored
      autogenModulesDir's proper name is autogenPackageModulesDir, and
      it's an autogenerated file directory that applies to ALL
      components in the package.  It lives in 'global-autogen'.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
    • Mikhail Glushenkov's avatar
      Merge pull request #3603 from 23Skidoo/internal-libs-check · a300cb2b
      Mikhail Glushenkov authored
      Check that all internal libraries have a name.
    • Mikhail Glushenkov's avatar
      80-col violations. · 3460b977
      Mikhail Glushenkov authored
    • Mikhail Glushenkov's avatar
    • bardur.arantsson's avatar
      Merge pull request #3601 from BardurArantsson/remove-dead-code · 11ea2294
      bardur.arantsson authored
      Remove dead code
    • bardur.arantsson's avatar
      Remove dead code · 03a50e74
      bardur.arantsson authored
    • Herbert Valerio Riedel's avatar
      New `cabal check` to warn about suspiciously short descriptions (#3479) · 165b6a05
      Herbert Valerio Riedel authored
      It seems that package authors are often unaware of the purpose of
      synopsis/description fields, and their impact on cabal and Hackage.  A
      common mistake is to write a verbose synopsis and leave the description
      field empty or even worse with useless boilerplate-text filled in by
      tooling, resulting in a suboptimal presentation on Hackage.
      The `synopsis` is supposed to be a terse <80 char description. In fact,
      the cabal user's guide states:
      > A very short description of the package, for use in a table of
      > packages. This is your headline, so keep it short (one line) but as
      > informative as possible. Save space by not including the package name
      > or saying it’s written in Haskell.
      On Hackage this synopsis is printed in the `<title>` and at the top of the
      package page, and is difficult to spot. However, the synopsis is
      displayed on Hackage in package lists or search results.
      On the other hand, the `description` field is rather important for
      `cabal info`  as well as the package cover-page, as it's printed below
      the "The $PKGNAME package"-heading, and above the properties section,
      and that's where everyone looks at.
      This new lint check is an attempt to point out a suspiciously short
      description field by using the heuristic of expecting the description
      field to be longer than the synopsis.
    • bardur.arantsson's avatar
      Remove top-down resolver · f357f778
      bardur.arantsson authored
      Removing 'topdown' as a resolver choice means that 'choose' is also
      obsolete and so it is removed too.
    • Herbert Valerio Riedel's avatar
      Implement `--allow-older` (dual to `--allow-newer`) (#3466) · 5944c3e9
      Herbert Valerio Riedel authored
      This implements the flag `--allow-older` which is the analogous to
      `--allow-newer` acting on lower bounds.
  4. 22 Jul, 2016 9 commits