This project is mirrored from Pull mirroring updated .
  1. 01 Oct, 2017 1 commit
  2. 28 Sep, 2017 1 commit
  3. 15 Aug, 2017 2 commits
  4. 23 Jul, 2017 1 commit
  5. 21 Jul, 2017 1 commit
  6. 10 Jul, 2017 1 commit
    • Douglas Wilson's avatar
      Refine "doingTH" check to include checking for QuasiQuotes · a0a506dd
      Douglas Wilson authored
      In several places we need to know whether any modules in the component being
      built use template haskell, because if they do we need to make sure the object
      files that will be needed are built.
      Previously, we checked whether TemplateHaskell was present in the extensions
      declared in the cabal file. Now we also check for QuasiQuotes.
      This patch adds usesTemplateHaskellOrQQ to Distribution.Types.BuildInfo and
      Distribution.PackageDescription. The checks "doingTH" checks in
      Distribuion.Simple.GHC, Distribution.Simple.GHCJS, and Distribution.Simple.LHC
      now delegate to usesTemplateHaskellOrQQ rather than each having identical checks
  7. 29 May, 2017 1 commit
  8. 25 May, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Workaround invalid .cabal files with Main modules in other-extensions · 47845856
      Herbert Valerio Riedel authored
      `other-modules` is intended for non-main modules (which is also stated
      in the cabal manual). Unfortunately, a few packages, such as `happy` do
      incorrectly specify `other-modules: Main` for their executables, thereby
      causing GHC to complain about duplicate Main modules.
      The workaround implemented here is to filter out the main module
      name (while taking into account `ghc-options: -main-is ...`) from the
      `other-modules` passed to GHC, and emit a warning in the process.
  9. 22 May, 2017 1 commit
  10. 05 May, 2017 1 commit
  11. 24 Mar, 2017 1 commit
  12. 22 Mar, 2017 1 commit
    • Duncan Coutts's avatar
      Simplify HcPkg.register interface · f3c43333
      Duncan Coutts authored
      Remove the variants reregister and registerMultiInstance and generalise
      the main register variant to cover them all. Introduce a RegisterOptions
      record for the variations.
      Eliminate an unused form where we supply a file rather than an
      InstalledPackageInfo value.
      The motivation is so we can more easily add yet more variations shortly.
      This is an API change.
  13. 19 Feb, 2017 1 commit
  14. 22 Jan, 2017 1 commit
  15. 09 Dec, 2016 1 commit
  16. 08 Dec, 2016 1 commit
  17. 26 Nov, 2016 1 commit
    • tulcod's avatar
      Implement foreign library versioning · 8744e30b
      tulcod authored
      This adds support for building foreign libraries with a given ABI version on Linux. This is enables foreign libraries to specify ABI compatibility information. This is important since ABI compatibility differs from package release versions.
      Two new fields are added: lib-version-info and lib-version-linux. The former accept versions Libtool-style, the latter sets SONAME versions directly. In both cases, appropriate symlinks are installed.
      Libtool accepts ABI version data via the -version-info flag, which takes current[:revision[:age]] data. This is then parsed into a version number. We copy this approach so that library versioning may be generalised to other operating systems than Linux.
  18. 18 Nov, 2016 1 commit
  19. 14 Nov, 2016 1 commit
  20. 31 Oct, 2016 1 commit
  21. 28 Oct, 2016 1 commit
    • Edsko de Vries's avatar
      Add support for foreign libraries. · 382143aa
      Edsko de Vries authored
      A stanza for a platform library looks something like
          platform-library test-package
            type:                native-shared
            if os(Windows)
              options: standalone
              mod-def-file: TestPackage.def
            other-modules:       MyPlatformLib.Hello
            build-depends:       base >=4.7 && <4.9
            hs-source-dirs:      src
            c-sources:           csrc/MyPlatformLibWrapper.c
            default-language:    Haskell2010
      where native-shared means that we want to build a native shared library
      (.so on Linux, .dylib on OSX, .dll on Windows). The parser also
      recognizes native-static but this is not currently supported anywhere.
      The standalone option means that the we merge all library dependencies
      into the dynamic library (i.e., ghc options -shared -static), rather
      than make the created dynamic library just record its dependencies (ghc
      options -shared -dynamic); it is currently compulsory on Windows and
      unsupported anywhere else. The mod-def-file can be used to specify a
      module definition file, and is also Windows specific.
      There is a bit of refactoring in Build: gbuild is the old buildOrReplExe
      and now deals with both executables and platform libraries.
  22. 17 Oct, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Workaround GHC #11214 by filtering JavaScriptFFI · 608517be
      Herbert Valerio Riedel authored
      Unfortunately, "native" GHC advertises support for `JavaScriptFFI` even though
      it doesn't support it. See also for respective
      However, in order to properly declare that packages require `JavaScriptFFI` support
      via `other-extensions` we need to fixup the list of extensions fed to the cabal solver.
      This patch does something similiar to the workaround we added some time ago to
      filter out TemplateHaskell for older GHCs which didn't properly advertise
      `TemplateHaskell` availability (c.f. 9f68eb44)
  23. 16 Oct, 2016 2 commits
    • Duncan Coutts's avatar
      Make sure ghc ignores any .ghc.environment files · ea1a2cd8
      Duncan Coutts authored
      When we invoke ghc in Cabal it's impostant that we control the
      environment. It's already the case that ghc ignores the .ghc.env files
      when we use -hide-all-packages, but there were a few places where we
      were not using this.
    • Duncan Coutts's avatar
      Add library support for writing ghc environment files · 8fd5ac5c
      Duncan Coutts authored
      This new ghc feature was actually added in ghc 7.10 but very limited,
      then extended significantly in 8.0.1 but with a severe bug for our use
      case and then should be working fine in 8.0.2 onwards.
      This patch adds basic support for writing .ghc.environment files. This
      feature will be used later in cabal-install, but it makes sense for the
      functionality to live in Cabal next to the other code that knows all
      too much about GHC.
      .ghc.environment file support works in ghc 8.0.2 onwards
      It was actually added in ghc 7.10 but very limited, then extended
      significantly in 8.0.1 but with a severe bug for our use case and
      then should be working fine in 8.0.2 onwards.
  24. 08 Oct, 2016 2 commits
  25. 06 Oct, 2016 3 commits
  26. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      Finally, this also adds a new functor-like convenience function
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      for modifying the version number components.
  27. 27 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `PackageName` type opaque (#3896) · dabd9d98
      Herbert Valerio Riedel authored
      When looking at heap-profiles of `cabal-install`, the `(:)` constructor
      stands out as the most-allocated constructor on the heap.
      Having to handle 10k+ package names contributes to the allocation
      numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
      per character footprint.
      This commit is a preparatory commit to pave the way for changing
      `PackageName`'s internal representation to something like
      `ShortByteString` (which is essentially a thin wrapper around primitive
      `ByteArray#`s which themselves have have an overhead of 2 words + one
      byte per ASCII character rounded up to nearest word) which would allow
      to reduce the memory footprint by a full order of magnitude, as well as
      reduce pointer chasing and GC overhead.
  28. 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.
  29. 11 Sep, 2016 2 commits
    • Lennart Kolmodin's avatar
      Only use portable isAbsolute/isRelative when we have to. (#3822) · 1b0560c6
      Lennart Kolmodin authored
      Only use the platform independent heuristics when we have to.
      Also rename the functions to isAbsoluteOnAnyPlatform and isRelativeOnAnyPlatform
      to make the distinction clearer.
    • ttuegel's avatar
      Revert "Respect GHC_PACKAGE_PATH" · 9c14b642
      ttuegel authored
      This reverts commit e7d2a62c due to a
      The package databases obtained from GHC_PACKAGE_PATH should be stored in
      the LocalBuildInfo and passed to GHC when necessary; otherwise, the user
      could change GHC_PACKAGE_PATH causing GHC and Cabal to see inconsistent
      installed package sets. cabal-install should trigger reconfiguration if
      GHC_PACKAGE_PATH changes.
  30. 09 Sep, 2016 1 commit
  31. 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 <>
  32. 06 Sep, 2016 3 commits