This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. 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: http://www.haskell.org/ghc/  :? 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: http://www.haskell.org/ghc/  :? 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: https://phabricator.haskell.org/D3298
      a7be1631
  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: https://phabricator.haskell.org/D1673
      01299ca8
  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: https://phabricator.haskell.org/D1611
      baed2f5a
    • 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
      5c789e42
      
      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
      (see https://github.com/haskell/cabal/pull/2946)
      
      This also updates a few submodules removing the now obsolete `--with-cc` flag
      support.
      
      Reviewed By: trofi, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1608
      fcc6b1de
  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 ld.gold
      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 `ld.gold` (or `${target}-ld.gold` when
      cross-compiling). In addition, simplifying the use of
      `$(CONF_GCC_LINKER_OPTS_STAGEn)`.
      
      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: https://phabricator.haskell.org/D715
      
      GHC Trac Issues: #8976 #9873
      71fcc4c0
  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
      Summary:
      If curses is installed into some non-standard path, we currently have
      to say something like the following in mk/build.mk:
      
        libraries/terminfo_CONFIGURE_OPTS += \
            --configure-option=--with-curses-includes=/somewhere/include \
            --configure-option=--with-curses-libraries=/somewhere/lib
      
      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: https://phabricator.haskell.org/D665
      
      GHC Trac Issues: #10096
      bbb57a6b
  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 https://github.com/haskell/cabal/issues/1622
      
       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 <hvr@gnu.org>
      8992d526
  12. 27 Mar, 2014 1 commit
  13. 01 Oct, 2013 1 commit
  14. 03 Jul, 2013 1 commit
    • ian@well-typed.com's avatar
      Change the ranlib detection · c548fec4
      ian@well-typed.com 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.
      c548fec4
  15. 14 May, 2013 2 commits
    • ian@well-typed.com's avatar
      Fix the GHC package DLL-splitting · 60b86b04
      ian@well-typed.com 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.
      60b86b04
    • ian@well-typed.com's avatar
      Simplify ghc-cabal · ff1a16a0
      ian@well-typed.com 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).
      ff1a16a0
  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:
      
      Before
      ------
      
      To build a cross-compiler:
        ./configure --target=<..>
      
      To compile a foreign GHC:
        ./configure --host=<..> --target=<..>
      
      Now
      ---
      
      To build a cross-compiler:
        ./configure --target=<..>
        And set "Stage1Only=YES" in mk/build.mk
      
      To compile a foreign GHC:
        ./configure --target=<..>
      109a1e53
  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
      d209588a
  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/validate.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)
      3d8dd486
  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.
      12646a9c
  33. 29 Apr, 2011 1 commit
  34. 27 Jan, 2011 1 commit
  35. 24 Jan, 2011 1 commit