1. 01 Mar, 2013 4 commits
  2. 26 Feb, 2013 1 commit
  3. 21 Feb, 2013 4 commits
  4. 20 Feb, 2013 1 commit
  5. 17 Feb, 2013 2 commits
  6. 16 Feb, 2013 2 commits
  7. 15 Feb, 2013 1 commit
  8. 05 Feb, 2013 1 commit
    • ian@well-typed.com's avatar
      Add a dependency of program modules on GHC.TopHandler · 40e43fa2
      ian@well-typed.com authored
      If you were unlucky, the build could fail, e.g.:
      
      utils\mkUserGuidePart\Main.hs:1:1:
          Failed to load interface for `GHC.TopHandler'
          There are files missing in the `base' package,
          try running 'ghc-pkg check'.
          Use -v to see a list of the files searched for.
      utils/mkUserGuidePart/ghc.mk:18: recipe for target `utils/mkUserGuidePart/dist/build/Main.o' failed
      40e43fa2
  9. 29 Jan, 2013 2 commits
  10. 25 Jan, 2013 1 commit
  11. 24 Jan, 2013 1 commit
  12. 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
  13. 10 Jan, 2013 1 commit
  14. 02 Jan, 2013 1 commit
  15. 30 Nov, 2012 1 commit
  16. 29 Nov, 2012 1 commit
  17. 13 Nov, 2012 1 commit
  18. 12 Nov, 2012 1 commit
    • ian@well-typed.com's avatar
      Replace mkDerivedConstants.c with DeriveConstants.hs · f49271c0
      ian@well-typed.com authored
      DeriveConstants.hs works in a cross-compilation-friendly way. Rather
      than running a C program that prints out the constants, we just compile
      a C file which has the constants are encoded in symbol sizes. We then
      parse the output of 'nm' to find out what the constants are.
      
      Based on work by Gabor Greif <ggreif@gmail.com>.
      f49271c0
  19. 02 Nov, 2012 1 commit
  20. 31 Oct, 2012 1 commit
  21. 26 Oct, 2012 1 commit
  22. 25 Oct, 2012 3 commits
  23. 24 Oct, 2012 1 commit
  24. 16 Oct, 2012 1 commit
  25. 14 Oct, 2012 1 commit
  26. 10 Oct, 2012 1 commit
  27. 04 Oct, 2012 1 commit
  28. 03 Oct, 2012 2 commits
    • ian@well-typed.com's avatar
      Windows install fix · 911bc5ce
      ian@well-typed.com authored
      911bc5ce
    • 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