1. 25 Jul, 2008 1 commit
  2. 18 Jul, 2008 2 commits
  3. 17 Jul, 2008 1 commit
  4. 11 Jul, 2008 1 commit
  5. 10 Jul, 2008 2 commits
  6. 05 Jul, 2008 2 commits
  7. 23 Jun, 2008 1 commit
  8. 28 May, 2008 1 commit
    • Simon Marlow's avatar
      Use MD5 checksums for recompilation checking (fixes #1372, #1959) · 526c3af1
      Simon Marlow authored
      This is a much more robust way to do recompilation checking.  The idea
      is to create a fingerprint of the ABI of an interface, and track
      dependencies by recording the fingerprints of ABIs that a module
      depends on.  If any of those ABIs have changed, then we need to
      recompile.
      
      In bug #1372 we weren't recording dependencies on package modules,
      this patch fixes that by recording fingerprints of package modules
      that we depend on.  Within a package there is still fine-grained
      recompilation avoidance as before.
      
      We currently use MD5 for fingerprints, being a good compromise between
      efficiency and security.  We're not worried about attackers, but we
      are worried about accidental collisions.
      
      All the MD5 sums do make interface files a bit bigger, but compile
      times on the whole are about the same as before.  Recompilation
      avoidance should be a bit more accurate than in 6.8.2 due to fixing
      #1959, especially when using -O.
      526c3af1
  9. 21 Feb, 2008 1 commit
  10. 18 Feb, 2008 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      All installed Haskell prgms have an inplace and an installed version · 3e274816
      chak@cse.unsw.edu.au. authored
      - GHC installs a range of compiled Haskell programs in addition to the actual
        compiler.  To ensure that they all run on the platform targeted by the build
        (which may have different libraries installed than the build host), we need
        to make sure that all compiled Haskell code going into an install is build
        with the stage 1 compiler, not the bootstrap compiler.  Getting this right
        is especially important on the Mac to enable builds that work on Mac OS X
        versions that are older than the one performing the build.
      - For all installed utils implemented in Haskell (i.e., ghc-pkg, hasktags,
        hsc2hs, runghc, hpc, and pwd) we compile two versions, an inplace version
        and a version for installation.  The former is build by the bootstrap
        compiler during the stage 1 build and the latter is build by the stage 1
        compiler during the stage 2 build.
      - This is really very much as the setup for ghc itself, only that we don't use
        separate stage1/ and stage2/ build directories.  Instead, we clean before
        each build.  CAVEAT: This only works properly if invoked from the 
        toplevel Makefile.
      - Instead of UseStage1=YES (as used by the previous binary-dist-specific
        recompilation), we now use the same $(stage) variables as used for the
        compiler proper - to increase uniformity and to avoid extra conditionals for
        the install target.
      3e274816
  11. 12 Jan, 2008 1 commit
  12. 25 Oct, 2007 1 commit
  13. 06 Sep, 2007 1 commit
    • Ian Lynagh's avatar
      Remove hardtop_plat/FPTOOLS_TOP_ABS_PLATFORM · c140c141
      Ian Lynagh authored
      They are now the same as hardtop/FPTOOLS_TOP_ABS, so use those instead.
      
      Also removed some substitutions of / for \, as we now use a Haskell
      program to find the top path, and it only makes paths with /s in.
      c140c141
  14. 28 Aug, 2007 1 commit
  15. 31 Jul, 2007 1 commit
  16. 05 Jul, 2007 1 commit
  17. 23 Jun, 2007 1 commit
  18. 22 Jun, 2007 1 commit
  19. 21 Jun, 2007 4 commits
  20. 15 Jun, 2007 1 commit
  21. 01 Jun, 2007 3 commits
  22. 31 May, 2007 1 commit
    • Ian Lynagh's avatar
      Rework the build system a bit · 430453c5
      Ian Lynagh authored
      Key changes:
      * Always build as if BIN_DIST is 1. BIN_DIST is thus removed.
      * Libraries are configured with prefix set to $$topdir rather than $(prefix)
      430453c5
  23. 09 May, 2007 1 commit
  24. 18 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fix bat-script generation for MSys · 58ec07c2
      simonpj@microsoft.com authored
      The bat-script generation was using the wrong paths, in
      	ghc-inplace
      	ghc-pkg
      	hsc2hs
      plus there was a double-backslah in the latter two which was wrong.
      This patch fixes both.  See "MSys Note 3" in compiler/Makefile
      
      58ec07c2
  25. 06 Apr, 2007 1 commit
  26. 15 Mar, 2007 1 commit
    • sven.panne@aedion.de's avatar
      Use update-alternatives for handling generic tool names · 1ee08bbe
      sven.panne@aedion.de authored
      ATTENTION: Packagers should read the following stuff carefully!
      
      GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the
      one hand this is quite handy, avoiding lots of tiny native packages, but OTOH
      this leads to a few problems:
      
         * The tools are not always identical in functionality.
      
         * The tools fight for a global generic name like "/usr/bin/runhaskell".
      
      These problems are not new and not unique to Haskell implementations, so for
      *nix-based system there is a tool called update-alternatives which handles
      those cases. The idea is as follows:
      
         * Each program/man page/etc. installs itself with a very specific name
           like /usr/bin/hsc2hs-ghc or /usr/share/man/man1/lua5.1.1.gz, so nothing
           clashes.
      
         * The (un-)installation scripts call update-alternatives to notify the
           system about new alternatives for a generic tool/manpage/etc.
      
         * Alternatives can be grouped together ("link groups"), so e.g. switching
           from Sun's Java to Kaffe switches compiler, JRE, manpages etc. together.
           Alas, this doesn't work well with the Haskell implementations yet,
           because they come with different sets of tools (in addition to runFOO):
      
             GHC:  hsc2hs
             Hugs: hsc2hs, cpphs
             nhc:  cpphs
      
           Either these tools should be disentangled fromt the Haskell
           implementations or all implementations should offer the same set.
           Opinions and recommendations on this topic are highly welcome.
      
         * This mechanism can be used to easily switch between several versions of
           the same implementation, too, but we are not yet fully prepared for that.
      
      As a first step, GHC now installs hsc2hs as 'hsc2hs-ghc' and does *not*
      install runhaskell directly anymore, only runghc. hsc2hs and runhaskell are
      created via update-alternatives now. What is currently missing is a mechanism
      for platforms like Windows and probably Mac OS X.
      1ee08bbe
  27. 09 Aug, 2006 1 commit
  28. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  29. 16 Jun, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-06-16 09:45:28 by simonmar] · 1957057d
      simonmar authored
      Move the boilerplate Makefile code for using libghccompat.a into a
      shared .mk file, lib/compat/compat.mk.  libghccompat.a is really a
      poor-mans package, but to make it a real package would mean dealing
      with variationg in the package support of different GHC versions, so
      this is easier for now.
      1957057d
  30. 14 Feb, 2005 1 commit
  31. 31 Jan, 2005 1 commit
  32. 28 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-28 12:55:17 by simonmar] · 153b9cb9
      simonmar authored
      Rationalise the BUILD,HOST,TARGET defines.
      
      Recall that:
      
        - build is the platform we're building on
        - host is the platform we're running on
        - target is the platform we're generating code for
      
      The change is that now we take these definitions as applying from the
      point of view of the particular source code being built, rather than
      the point of view of the whole build tree.
      
      For example, in RTS and library code, we were previously testing the
      TARGET platform.  But under the new rule, the platform on which this
      code is going to run is the HOST platform.  TARGET only makes sense in
      the compiler sources.
      
      In practical terms, this means that the values of BUILD, HOST & TARGET
      may vary depending on which part of the build tree we are in.
      
      Actual changes:
      
       - new file: includes/ghcplatform.h contains platform defines for
         the RTS and library code.
      
       - new file: includes/ghcautoconf.h contains the autoconf settings
         only (HAVE_BLAH).  This is so that we can get hold of these
         settings independently of the platform defines when necessary
         (eg. in GHC).
      
       - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.
      
       - MachRegs.h, which is included into both the compiler and the RTS,
         now has to cope with the fact that it might need to test either
         _TARGET_ or _HOST_ depending on the context.
      
       - the compiler's Makefile now generates
           stage{1,2,3}/ghc_boot_platform.h
         which contains platform defines for the compiler.  These differ
         depending on the stage, of course: in stage2, the HOST is the
         TARGET of stage1.  This was wrong before.
      
       - The compiler doesn't get platform info from Config.hs any more.
         Previously it did (sometimes), but unless we want to generate
         a new Config.hs for each stage we can't do this.
      
       - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
         in CPP'd Haskell source.
      
       - ghcplatform.h defines *_TARGET_* for backwards compatibility
         (ghcplatform.h is included by ghcconfig.h, which is included by
         config.h, so code which still #includes config.h will get the TARGET
         settings as before).
      
       - The Users's Guide is updated to mention *_HOST_* rather than
         *_TARGET_*.
      
       - coding-style.html in the commentary now contains a section on
         platform defines.  There are further doc updates to come.
      
      Thanks to Wolfgang Thaller for pointing me in the right direction.
      153b9cb9