This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 07 Aug, 2016 1 commit
  2. 06 Aug, 2016 1 commit
  3. 02 Aug, 2016 4 commits
  4. 01 Aug, 2016 3 commits
  5. 28 Jul, 2016 2 commits
  6. 26 Jul, 2016 6 commits
  7. 25 Jul, 2016 4 commits
  8. 24 Jul, 2016 2 commits
    • Edward Z. Yang's avatar
      Implement --cabal-file, allows multiple Cabal files in directory · e507ca84
      Edward Z. Yang authored
      
      
      This is primarily intended for use with the Cabal test suite (allowing
      us to easily specify multiple Cabal packages for the same Haskell source
      files), but maybe some end-users will find it useful as well.  If there
      are multiple Cabal files in the current working directory, --cabal-file
      (for configure) allows you to disambiguate which one to build with.
      
      There's a big hack to handle the BOM check, as it is inconvenient to
      plumb the flag value all the way to the check code.  Some bigger
      refactoring needed, see #3552.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e507ca84
    • Edward Z. Yang's avatar
      As much as possible, expunge uses of localPkgDescr. · e3c64e6d
      Edward Z. Yang authored
      
      
      The big change here is that most of the functions in
      Distribution.Types.HookedBuildInfo have to take a
      PackageDescription explicitly.  I hate the new type,
      so I primed these new functions, and added functions
      which use 'localPkgDescr'.  Presently those have WARNINGs
      attached to them so people don't accidentally use them;
      once we fix 'HookedBuildInfo' we can change this.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e3c64e6d
  9. 23 Jul, 2016 8 commits
    • Edward Z. Yang's avatar
      69e19add
    • 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 <ezyang@cs.stanford.edu>
      d94ddc0e
    • 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 <ezyang@cs.stanford.edu>
      ff6aa2f0
    • Edward Z. Yang's avatar
    • Mikhail Glushenkov's avatar
      80-col violations. · 3460b977
      Mikhail Glushenkov authored
      3460b977
    • Mikhail Glushenkov's avatar
      e0515186
    • 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.
      165b6a05
    • 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.
      5944c3e9
  10. 22 Jul, 2016 8 commits
  11. 21 Jul, 2016 1 commit