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 1 commit
  4. 28 Jul, 2016 2 commits
  5. 26 Jul, 2016 2 commits
  6. 25 Jul, 2016 2 commits
  7. 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
  8. 23 Jul, 2016 5 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
    • 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
  9. 22 Jul, 2016 4 commits
  10. 21 Jul, 2016 3 commits
  11. 19 Jul, 2016 1 commit
  12. 11 Jul, 2016 5 commits
  13. 24 May, 2016 1 commit
    • Benno Fünfstück's avatar
      haddock/hscolour: fix highlighted source location · 09753724
      Benno Fünfstück authored
      When generating haddocks with the `--for-hackage` switch, the generated
      haddocks are placed in a different directory than the normal ones, which
      includes the package id instead of just the package name. When we ran
      hscolour, we didn't respect this, so the highlighted source would not
      be placed in the correct directory and thus was missing from the tarball.
      This patch fixes that.
      
      Fixes #3451
      09753724
  14. 19 May, 2016 1 commit
  15. 07 May, 2016 2 commits
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Report process output decoding errors in context · cc35a48a
      Duncan Coutts authored
      It turns out that in rawSystemStdInOut any IO errors, including text
      decoding, occurring while collecting the output (stderr or stdout) do
      not get reported immediately, but only later if/when the output is
      consumed. This is because the exceptions happened in the threads forked
      to force the output, but if the main thread looks at the output later
      then the exception is reported again.
      
      This leads to very confusing results. In particular we had a case where
      the configure process did not fail until writing out the LocalBuildInfo
      because that was the first point that forced the output. So the distance
      from when the exception really occurred and the fact that the exception
      message does not include the name of the program run means that this is
      then a pain to track down.
      
      This patch makes sure that any exceptions arising from forcing the
      program output occur immediately and with an error message that includes
      the name of the program in question.
      cc35a48a
  16. 06 May, 2016 1 commit
    • randen's avatar
      Add Verbose-level logging of the haddock response-file · 3579e749
      randen authored
      contents. Prior to the response file code, all of these
      details of the command line for haddock would have been
      logged (with level == Verbose), so this corrects an oversight
      and brings the information in the logging back to what it
      used to be for cabal's haddock invocations.
      
      * Cabal/Distribution/Simple/Haddock.hs
        * Restore the logging of the entire command line used when
          invoking haddock to what it used to be prior to adding
          the response-file creation.
      
      (cherry picked from commit 28bea0d7)
      3579e749
  17. 25 Apr, 2016 1 commit
  18. 14 Apr, 2016 1 commit
  19. 12 Apr, 2016 4 commits