1. 29 Jun, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add BUILD_DPH variable to GHC build-system · 88d85aa6
      Herbert Valerio Riedel authored
      Now that the `libraries/dph` submodule is checked out always we need
      a different way to disable building DPH to save compile-time while
      developing GHC.
      This commit adds a new YES/NO Make variable `BUILD_DPH` that can be used
      inside mk/build.mk to control whether to build libraries/dph or not.
      The default setting is `BUILD_DPH=YES` (via `mk/config.mk.in`).
      This also changes `validate`'s flag `--no-dph` to explicitly disable DPH
      for the current validation run.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      Test Plan: successful validates with `--fast --no-dph`
      Differential Revision: https://phabricator.haskell.org/D31
  2. 09 Jun, 2014 1 commit
  3. 03 May, 2014 1 commit
  4. 22 Apr, 2014 1 commit
  5. 31 Mar, 2014 1 commit
  6. 26 Feb, 2014 1 commit
  7. 20 Feb, 2014 1 commit
  8. 09 Feb, 2014 2 commits
  9. 31 Jan, 2014 2 commits
  10. 28 Jan, 2014 1 commit
  11. 17 Jan, 2014 1 commit
    • Austin Seipp's avatar
      Fix #8675 · e4a4abae
      Austin Seipp authored
      Haddock no longer has a generated parser, so we don't need it in the
      sdist and we certainly don't want to check for it in the ./configure
      script (as that would be bogus.)
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
  12. 25 Oct, 2013 1 commit
  13. 01 Oct, 2013 1 commit
  14. 15 Sep, 2013 1 commit
  15. 15 Aug, 2013 1 commit
    • thoughtpolice's avatar
      Don't delete HsTimeConfig.h.in during distclean. · 94c35ddf
      thoughtpolice authored
      sdist preps the tree via distclean before anything else, which caused
      HsTimeConfig.h.in under 'time' to be deleted - even though it should be
      included in the resulting tarball for ./configure.
      The correct target is 'maintainer-clean'.
      I'm guessing the nightlies didn't complain because they run ./boot,
      forcing regeneration. NixOS's Hydra does not, though.
      Thanks to Peter Simons and Andres Löh for pointing this out.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
  16. 14 Aug, 2013 1 commit
  17. 30 Jul, 2013 1 commit
  18. 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.
  19. 22 Jun, 2013 1 commit
  20. 14 Jun, 2013 1 commit
  21. 09 Jun, 2013 4 commits
  22. 25 May, 2013 1 commit
  23. 19 May, 2013 1 commit
  24. 14 May, 2013 2 commits
  25. 12 May, 2013 2 commits
    • Ian Lynagh's avatar
      More work towards dynamic programs on Windows · b35a6ce0
      Ian Lynagh authored
      Dynamic GHC is now working in-place, but pathologically slow due
      to the DLL split.
      (GHC assumes that all intra-package calls are in the same DLL, but that
      isn't true when we split the GHC package into 2 DLLs. That means that
      GHC's startup time is around 22 seconds, as it is doing run-time
      Also, ghci isn't actually working yet:
      $ inplace/bin/ghc-stage2 --interactive
      GHCi, version 7.7.20130512: http://www.haskell.org/ghc/  :? for help
      Loading package ghc-prim ... <command line>: can't load .so/.DLL for:
      HSghc-prim- (addDLL: could not load DLL)
      ghc-stage2.exe: HSghc-prim- The specified module could not be
    • Ian Lynagh's avatar
      We actually need to use -threaded/-debug when linking /all/ DLLs · b2cae55f
      Ian Lynagh authored
      Not just base, integer-gmp and ghc-prim.
  26. 10 May, 2013 1 commit
  27. 09 May, 2013 1 commit
    • ian@well-typed.com's avatar
      Fix dynamically linked GHC on Windows · a5a52d79
      ian@well-typed.com authored
      This is a rather ugly hack to fix dynamically linked GHC on Windows.
      If GHC is linked with -threaded, then it links against libHSrts_thr.
      But if base is linked against libHSrts, then both end up getting
      loaded, and things go wrong. We therefore link the libraries that
      link against the RTS with the same RTS flags that we link GHC with.
  28. 21 Apr, 2013 1 commit
  29. 20 Apr, 2013 5 commits