This project is mirrored from Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 15 Mar, 2017 1 commit
    • Simon Marlow's avatar
      Always build GHCi libs · a7be1631
      Simon Marlow authored and Ben Gamari's avatar Ben Gamari committed
      Since the introduction of -split-sections, using GHCi with the RTS
      linker is really slow:
      $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter)
      GHCi, version 8.1.20170304:  :? for help
      Prelude> Leaving GHCi.
      real        0m3.793s
      (when we use `-fexternal-interpreter` it uses the RTS linker by default,
      you can make it use the system linker by adding `-dynamic`)
      Building the GHCi libs doesn't take much time or space in the GHC build,
      but makes things much quicker for people using the RTS linker:
      $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter)
      GHCi, version 8.1.20170304:  :? for help
      Prelude> Leaving GHCi.
      real        0m0.285s
      So I propose that we build and ship them unconditionally.
      Test Plan: validate, perf tests above
      Reviewers: bgamari, austin, niteria, erikd, Phyx
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, snowleopard
      Differential Revision:
  2. 08 Feb, 2017 1 commit
  3. 30 Jun, 2016 1 commit
  4. 27 Mar, 2016 1 commit
  5. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      Reviewed By: bgamari, thomie, ezyang
      Differential Revision:
  6. 14 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Don't pass CC= explicitly to `./configure` scripts · baed2f5a
      Herbert Valerio Riedel authored
      This is a follow-up to fcc6b1de / D1608 which is made possible
      by the recent Cabal update:
      As `ghc-cabal` is called with `--with-gcc`, this gets passed to `./configure`
      as `CC=...` argument. So we don't need to set `CC=...` ourselves explicitly again.
      Prior to the changes in Cabal (pulled in via  0bf0cf93) and fcc6b1de,
      `./configure` scripts would be called with a `--with-cc` argument followed by a
      `--with-gcc` argument.
      After this commit, `./configure` will be passed a single `CC=...` argument
      constructed by the `Cabal` library.
      Reviewed By: erikd
      Differential Revision:
    • Herbert Valerio Riedel's avatar
      Use idiomatic way to tell Autoconf the c compiler · fcc6b1de
      Herbert Valerio Riedel authored
      The non-idiomatic `--with-cc` flag was added via
      However, `--with-cc` seems rather fragile and support for `--with-cc` needs
      to be added explicitly to autoconf-based Cabal packages. The `CC=` flag, however,
      is supported natively by GNU Autoconf, so let's use the standard facility for that.
      Relatedly, Cabal prior to version 1.24 used a similiar flag `--with-gcc=...`,
      but starting with Cabal-1.24 this has been changed to use `CC=...` instead as well
      This also updates a few submodules removing the now obsolete `--with-cc` flag
      Reviewed By: trofi, thomie, erikd
      Differential Revision:
  7. 13 Jul, 2015 1 commit
  8. 04 Jun, 2015 1 commit
  9. 12 Mar, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Use the gold linker for linux/ARM and android/ARM targets. · 71fcc4c0
      Erik de Castro Lopo authored
      Fixes #8976 and #9873 by making use of the Binutils
      linker explicit whenever the target is linux/ARM or android/ARM.
      This does not affect iOS where Apple provides its own linker.
      In order to achieve this, we need to add `-fuse-ld=gold` to
      the SettingsCCompilerLinkFlags setting and set
      SettingsLdCommand to `` (or `${target}` when
      cross-compiling). In addition, simplifying the use of
      This patch was tested by ensuring that the following worked
      as expected:
        * Native builds on linux/x86_64 (nothing changed).
        * Native builds on linux/arm (and uses the gold linker).
        * Linux to linux/arm cross compiles (and uses the cross
          gold linker).
      Contributions by Ben Gamari, Joachim Breitner and Reid Barton.
      Reviewers: nomeata, bgamari, austin, rwbarton
      Subscribers: thomie
      Differential Revision:
      GHC Trac Issues: #8976 #9873
  10. 23 Feb, 2015 1 commit
    • PHO's avatar
      Make top-level "configure" accept and propagate --with-curses-{includes,libraries} to libraries · bbb57a6b
      PHO authored
      If curses is installed into some non-standard path, we currently have
      to say something like the following in mk/
        libraries/terminfo_CONFIGURE_OPTS += \
            --configure-option=--with-curses-includes=/somewhere/include \
      This is because the top-level configure does not accept nor propagate
      --with-curses-{includes,libraries} to libraries while it does so for
      iconv, gmp and libffi. It would be nice if curses were handled in the
      same manner.
      Test Plan: Install curses into some non-standard path. Then run the top-level "configure" script with options "--with-curses-includes=/path/to/curses/include" and "--with-curses-libraries=/path/to/curses/lib".
      Reviewers: austin
      Reviewed By: austin
      Subscribers: thomie, PHO
      Differential Revision:
      GHC Trac Issues: #10096
  11. 16 Apr, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Update Cabal submodule to tip of v1.20 branch · 8992d526
      Herbert Valerio Riedel authored
      This corresponds to the RC of the soon-to-be Cabal 1.20 release
      One noteworthy change is the removal of the `--with-ranlib` flag
      requiring a small adaptation in the GHC build system.
      Moreover two new licences were added, MPL and BSD2.
      Due to
       Cabal-1.20 now
      allows to strip libraries as well, this doesn't work well with
      `ghc-cabal copy` being fed a `":"` strip-command argument which was
      simply ignored in the past. The current code tries to retain this
      semantics as backward compat. However, this needs more investigation as
      I'm not sure if/why the `test_bindist` step doesn't want the libraries
      to be stripped on installation.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <>
  12. 27 Mar, 2014 1 commit
  13. 01 Oct, 2013 1 commit
  14. 03 Jul, 2013 1 commit
    •'s avatar
      Change the ranlib detection · c548fec4 authored
      On Windows, the ranlib in the path may not be the right ranlib (it may
      be the 32bit ranlib when we are making a Win64 compiler, or vice-versa).
      Therefore we can't leave it up to libffi to detect the right ranlib, but
      need to tell it which ranlib to use. This means that we need to find
      ranlib even if we don't actually need it ourselves.
  15. 14 May, 2013 2 commits
    •'s avatar
      Fix the GHC package DLL-splitting · 60b86b04 authored
      There's now an internal -dll-split flag, which we use to tell GHC how
      the GHC package is split into 2 separate DLLs. This is used by
      Packages.isDllName to determine whether a call is within the same
      DLL, or whether it is a call to another DLL.
    •'s avatar
      Simplify ghc-cabal · ff1a16a0 authored
      It now consistently takes directory and distDirectory as its first 2
      arguments. Also, it only supports configuring 1 package at a time now
      (we weren't using the ability to configure more than one at once).
  16. 20 Apr, 2013 1 commit
  17. 15 Mar, 2013 1 commit
  18. 11 Mar, 2013 1 commit
  19. 03 Mar, 2013 1 commit
  20. 17 Feb, 2013 2 commits
  21. 15 Feb, 2013 1 commit
  22. 17 Jan, 2013 1 commit
    • Simon Marlow's avatar
      Tidy up cross-compiling · 109a1e53
      Simon Marlow authored
      We have two cases:
       1. building a cross-compiler
       2. compiling GHC to run on a foreign platform
      These two are done with almost the same setup: (1) is the stage 1
      compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
      The only difference between (1) and (2) is that you if you set up the
      build for (1), then it stops before stage 2 and you can 'make install'
      to install stage 1.
      Unfortunately, (2) didn't work, and the build system code needed some
      tidying up.
      Change to the way the build is set up:
      To build a cross-compiler:
        ./configure --target=<..>
      To compile a foreign GHC:
        ./configure --host=<..> --target=<..>
      To build a cross-compiler:
        ./configure --target=<..>
        And set "Stage1Only=YES" in mk/
      To compile a foreign GHC:
        ./configure --target=<..>
  23. 16 Jan, 2013 2 commits
  24. 25 Oct, 2012 1 commit
  25. 24 Oct, 2012 1 commit
  26. 14 Oct, 2012 1 commit
  27. 29 Jun, 2012 2 commits
  28. 27 Apr, 2012 1 commit
    • Iavor S. Diatchki's avatar
      A build-system tweak for more readable build output. · d209588a
      Iavor S. Diatchki authored
      This change reduces the (default) verbosity of the build system.
      This makes it easier to spot warnings in the output and, also, it
      makes it easier to estimate how far along are we in the build process
      by just glancing at the output.
      To get the traditional fully verbose output, set V=1, like this:
          make V=1
  29. 26 Apr, 2012 1 commit
    • Ian Lynagh's avatar
      Add SRC_[CH]C_WARNING_OPTS · 3d8dd486
      Ian Lynagh authored
      This allows you to say things like
          SRC_HC_WARNING_OPTS += -fno-warn-unsupported-calling-conventions
      in mk/
      Unfortunately, we can't just use SRC_HC_OPTS, as that gets put before
      the more specific options (e.g. ghc-options in a .cabal file), many of
      which include -Wall. So now we have:
          ghc $(SRC_HC_OPTS) ... options from .cabal etc ... $(SRC_HC_WARNING_OPTS)
  30. 30 Jan, 2012 1 commit
  31. 28 Jan, 2012 1 commit
  32. 28 Aug, 2011 1 commit
    • Ian Lynagh's avatar
      By default, be lax about dependencies on GHC · 12646a9c
      Ian Lynagh authored
      There are a number of things which technically depend on GHC (e.g. if
      ghc changes then Haskell files may be compiled differently, or Cabal
      packages may be configured differently). However, in practice, having
      a real dependency on GHC is just a pain: We normally don't want to
      spend time recompiling other things while we're working on the
      compiler, and even if we did, GHC will normally decide compilation
      isn't needed anyway. So by default we use order-only dependencies on
      GHC, i.e. GHC must exist, but if it's newer than other targets then
      rebuilding is not necessary.
  33. 29 Apr, 2011 1 commit
  34. 27 Jan, 2011 1 commit
  35. 24 Jan, 2011 1 commit