1. 29 Aug, 2014 1 commit
  2. 05 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D80
      66218d15
  3. 28 Jul, 2014 1 commit
  4. 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
      88d85aa6
  5. 09 Jun, 2014 1 commit
  6. 03 May, 2014 1 commit
  7. 22 Apr, 2014 1 commit
  8. 31 Mar, 2014 1 commit
  9. 26 Feb, 2014 1 commit
  10. 20 Feb, 2014 1 commit
  11. 09 Feb, 2014 2 commits
  12. 31 Jan, 2014 2 commits
  13. 28 Jan, 2014 1 commit
  14. 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
  15. 25 Oct, 2013 1 commit
  16. 01 Oct, 2013 1 commit
  17. 15 Sep, 2013 1 commit
  18. 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
  19. 14 Aug, 2013 1 commit
  20. 30 Jul, 2013 1 commit
  21. 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
  22. 22 Jun, 2013 1 commit
  23. 14 Jun, 2013 1 commit
  24. 09 Jun, 2013 4 commits
  25. 25 May, 2013 1 commit
  26. 19 May, 2013 1 commit
  27. 14 May, 2013 2 commits
  28. 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
  29. 10 May, 2013 1 commit
  30. 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
  31. 21 Apr, 2013 1 commit
  32. 20 Apr, 2013 2 commits