1. 09 Feb, 2014 1 commit
  2. 31 Jan, 2014 2 commits
  3. 28 Jan, 2014 1 commit
  4. 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>
      e4a4abae
  5. 25 Oct, 2013 1 commit
  6. 01 Oct, 2013 1 commit
  7. 15 Sep, 2013 1 commit
  8. 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>
      94c35ddf
  9. 14 Aug, 2013 1 commit
  10. 30 Jul, 2013 1 commit
  11. 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
  12. 22 Jun, 2013 1 commit
  13. 14 Jun, 2013 1 commit
  14. 09 Jun, 2013 4 commits
  15. 25 May, 2013 1 commit
  16. 19 May, 2013 1 commit
  17. 14 May, 2013 2 commits
  18. 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
      linking).
      
      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-0.3.1.0.dll (addDLL: could not load DLL)
      ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be
      found.
      b35a6ce0
    • 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.
      b2cae55f
  19. 10 May, 2013 1 commit
  20. 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.
      a5a52d79
  21. 21 Apr, 2013 1 commit
  22. 20 Apr, 2013 7 commits
  23. 19 Apr, 2013 3 commits
  24. 07 Apr, 2013 3 commits