This project is mirrored from Pull mirroring updated .
  1. 22 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Update default-language & avoid default-extensions (#3880) · f87738df
      Herbert Valerio Riedel authored
      This upgrades the `default-language: Haskell98` to `Haskell2010`
      and removes `default-extensions: RankNTypes, FlexibleContexts`
      in favor of adding `LANGUAGE` pragmas where needed.
      Moroever, this also drops `LANGUAGE` pragmas which have become redundant
      due to `Haskell2010` (specifically, `EmptyDataDecls`,
      `ForeignFunctionInterface` and `PatternGuards`)
      Finally, an `other-extensions` specification is put in place for the
      `Cabal` library component.
      This helps loading up files directly in GHCi, such as e.g. `ghci Setup.hs`
      without having to specify `-X...` flags.
  2. 13 Sep, 2016 1 commit
  3. 08 Sep, 2016 1 commit
    • Edward Z. Yang's avatar
      Provide useful call-stacks over all IO code. · 48a0d6ce
      Edward Z. Yang authored
      The key idea is that we define:
          type IO a = HasCallStack => Prelude.IO a
      and voila, call stacks are maintained across all IO!  You can
      look at the stacks using -v"debug +callstack".
      There are a number of IO functions for which the call stack is
      never used.  They are explicitly annotated using NoCallStackIO.
      Maybe some day they will use call stacks and we can change their
      types.  Similarly, there are a number of functions which do
      have type IO, but then suppress the redundant constraint error
      using "_ = callStack". Maybe some day we will attach call
      stacks to the exceptions we throw.
      Signed-off-by: default avatarEdward Z. Yang <>
  4. 06 Sep, 2016 3 commits
  5. 21 Aug, 2016 2 commits
    • Edward Z. Yang's avatar
      One-component configure, fixes #2802. · a090a494
      Edward Z. Yang authored
      Described in:
      ./Setup configure now takes an argument to specify a specific
      component name that should solely be configured.
      Most of the gyrations in Configure are all about making it so that
      we can feed in internal dependencies via --dependency.
      I dropped the package name match sanity check to handle convenience
      library package name munging.  Consider an internal library named
      'q' in package 'p'.  When we install it to the package database,
      we munged the package name into 'z-p-z-q', so that it doesn't
      conflict with the actual package named 'q'.  Now consider when
      we feed it in with --dependency q=p-0.1-hash-q.  Previously,
      Cabal checked that the 'q' in --dependency matched the package
      name in the database... which it doesn't. So I dropped the check.
      I also had to make register/copy unconditionally install internal
      libraries; otherwise you can't refer to them from later builds.
      Also a miscellaneous refactor: convenience libraries are printed with a
      "header" stanza now (not really a stanza header).
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
  6. 26 Jul, 2016 3 commits
  7. 24 Jul, 2016 1 commit
    • 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 <>
  8. 22 Jul, 2016 1 commit
  9. 11 Jul, 2016 1 commit
  10. 12 Apr, 2016 1 commit
  11. 08 Apr, 2016 1 commit
  12. 29 Mar, 2016 4 commits
  13. 29 Feb, 2016 1 commit
  14. 27 Feb, 2016 1 commit
  15. 30 Jan, 2016 1 commit
  16. 25 Jan, 2016 1 commit
  17. 08 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Remove same-package import lists, fixes #2835. · 639cd007
      Edward Z. Yang authored
      Instead of qualifying, in some cases I just added an extra
      'hiding' pragma to squelch errors.  Common conflicts
      (just grep for hiding):
          - Flag
              - Distribution.Simple.Compiler
              - Distribution.PackageDescription
              - Distribution.Simple.Setup
          - installedComponentId
              - Distribution.Package
              - Distribution.InstalledPackageInfo
          - doesFileExist
              - Distribution.PackageDescription.Check
          - instantiatedWith
              - I renamed the field in InstalledPackageInfo.  But
                it's probably going away with Backpack bits; I
                migth just excise it soon.
          - absoluteInstallDirs and substPathTemplate
              - Distribution.Simple.InstallDirs
              - Distribution.Simple.LocalBuildInfo
      I fixed some shadowing errors by renaming local variables in some cases.
      Common shadowings (we should perhaps consider not using these as
      method/field names):
          - freeVars
          - components
          - noVersion
          - verbosity
          - get
          - description
          - name
      Some data structures were moved around (IPIConvert and ABIHash)
      to make it easier to handle import lists.
      Some functions in Utils could be turned into reexports of standard
      library functions.
      No explicit imports were removed from non-Cabal imports.  These
      imports help maintain warning cleanliness across versions of GHC,
      so I don't recommend removing them.
      Signed-off-by: default avatarEdward Z. Yang <>
  18. 31 Dec, 2015 1 commit
  19. 28 Dec, 2015 1 commit
  20. 13 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Use standard mechanism to tell ./configure the c-compiler · 47259753
      Herbert Valerio Riedel authored
      Most Autoconf configure scripts don't support the non-standard `--with-gcc`
      flag, and there does not seem to be any good reason to do so, since
      Autoconf has already a proper way to set the c-compiler:
      Either via the `CC` environment variable, or (with higher precedence)
      by passing a commandline argument of the form `CC=clang-3.8`.
      This patch simply replaces the previous non-standard `--with-gcc=clang-3.8`
      argument (which was clearly misnamed to begin with) by a `CC=clang-3.8`
      command-line argument to the `configure` script.
  21. 26 Sep, 2015 2 commits
  22. 27 Jun, 2015 1 commit
    • ttuegel's avatar
      Get 'builddir' from cabal.config or CABAL_BUILDDIR · 2b3282fc
      ttuegel authored
      Fixes #2484. The 'builddir' option may now be specified in cabal.config
      as well. It will also be read from the CABAL_BUILDDIR environment
      variable, if set. The order of precedence (highest to lowest) is:
      1. --builddir command line option
      2. CABAL_BUILDDIR environment variable
      3. cabal.config setting
  23. 31 May, 2015 1 commit
  24. 31 Mar, 2015 1 commit
  25. 23 Feb, 2015 1 commit
  26. 07 Dec, 2014 1 commit
    • Lennart Spitzner's avatar
      Change globalCommands description generation · d54a98b1
      Lennart Spitzner authored
      - previously, runCommands internally modified the description
        by adding the list of commands.
      - now, globalCommands is a function that builds the complete
        description without need for changes during runCommands invocation.
      - slightly more code duplication, but better separation of concerns
  27. 02 Jul, 2014 1 commit
  28. 21 Apr, 2014 2 commits
  29. 14 Apr, 2014 1 commit
  30. 02 Feb, 2014 1 commit