1. 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
  2. 12 May, 2013 1 commit
    • 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
  3. 13 Mar, 2013 1 commit
  4. 12 Mar, 2013 1 commit
  5. 11 Mar, 2013 1 commit
  6. 25 Oct, 2012 2 commits
  7. 24 Oct, 2012 1 commit
  8. 14 Oct, 2012 2 commits
  9. 03 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Build the dynamic way by default on Linux/amd64 · 898cb090
      ian@well-typed.com authored
      This required various build system changes to get the build to go
      through.
      
      In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
      to find their libraries. In the future, we might change the inplace tree
      to be the same shape as an installed tree instead. However, this would
      mean changing the way we do installation, as currently we use cabal's
      installation methods to install the libraries, but that only works if
      the libraries are under libraries/foo/dist-install/build/..., rather
      than in inplace/lib/...
      898cb090
  10. 23 Aug, 2012 1 commit
  11. 15 May, 2012 1 commit
    • pcapriotti's avatar
      Rename package-conf flags to package-db. · ca2debb2
      pcapriotti authored
      Rename package database flags in both GHC and ghc-pkg so that they are
      consistent with Cabal nomenclature.
      
      Add a version check to the build system so that the correct set of
      package db flags are used when the bootstrapping GHC has version < 7.5.
      ca2debb2
  12. 07 May, 2012 1 commit
  13. 25 May, 2011 1 commit
  14. 17 Apr, 2011 1 commit
  15. 24 Jan, 2011 1 commit
    • Simon Marlow's avatar
      Merge in new code generator branch. · 889c084e
      Simon Marlow authored
      This changes the new code generator to make use of the Hoopl package
      for dataflow analysis.  Hoopl is a new boot package, and is maintained
      in a separate upstream git repository (as usual, GHC has its own
      lagging darcs mirror in http://darcs.haskell.org/packages/hoopl).
      
      During this merge I squashed recent history into one patch.  I tried
      to rebase, but the history had some internal conflicts of its own
      which made rebase extremely confusing, so I gave up. The history I
      squashed was:
      
        - Update new codegen to work with latest Hoopl
        - Add some notes on new code gen to cmm-notes
        - Enable Hoopl lag package.
        - Add SPJ note to cmm-notes
        - Improve GC calls on new code generator.
      
      Work in this branch was done by:
         - Milan Straka <fox@ucw.cz>
         - John Dias <dias@cs.tufts.edu>
         - David Terei <davidterei@gmail.com>
      
      Edward Z. Yang <ezyang@mit.edu> merged in further changes from GHC HEAD
      and fixed a few bugs.
      889c084e
  16. 22 Jan, 2011 1 commit
  17. 19 Jan, 2011 2 commits
  18. 17 Jan, 2011 1 commit
  19. 12 Dec, 2010 1 commit
  20. 10 Dec, 2010 1 commit
  21. 27 Nov, 2010 1 commit
  22. 20 Oct, 2010 1 commit
  23. 29 Sep, 2010 1 commit
  24. 13 Sep, 2010 1 commit
  25. 18 Aug, 2010 1 commit
  26. 13 Jan, 2010 1 commit
  27. 12 Jan, 2010 1 commit
    • Simon Marlow's avatar
      Invoke Haddock directly from the build system, instead of via Cabal · a4bef988
      Simon Marlow authored
      Partly this is cleaner as we only have to preprocess the source files
      once, but also it is necessary to avoid Haddock recompiling source
      files when Template Haskell is in use, saving some time in validate
      and fixing a problem whereby when HADDOCK_DOCS=YES, make always
      re-haddocks the DPH packages.  This also needs an additional fix to
      GHC.
      
      HsColour support still uses Cabal, and hence preprocesses the source
      files again. We could move this into the build system too, but there
      is a version dependency that would mean adding extra autoconf stuff.
      a4bef988
  28. 29 Nov, 2009 1 commit
  29. 10 Nov, 2009 1 commit
  30. 08 Nov, 2009 2 commits
  31. 05 Nov, 2009 1 commit
  32. 06 Oct, 2009 1 commit
  33. 27 Sep, 2009 1 commit
  34. 21 Sep, 2009 1 commit
  35. 15 Sep, 2009 1 commit