This project is mirrored from Pull mirroring updated .
  1. 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.
  2. 22 Jul, 2016 17 commits
  3. 21 Jul, 2016 9 commits