1. 20 Sep, 2004 1 commit
    • panne's avatar
      [project @ 2004-09-20 17:53:40 by panne] · 8c1c956b
      panne authored
      Removed dependency of $(TOP)/mk/config.mk on $(TOP)/config.status, resurrecting
      "make distclean". I'm not 100% sure that the autoconf-related rules are correct,
      "./config.status --recheck" in conjunction with make is a real brain-twister...
  2. 10 Sep, 2004 1 commit
  3. 07 Sep, 2004 1 commit
  4. 18 Aug, 2003 1 commit
  5. 06 Jun, 2003 1 commit
  6. 14 Jan, 2003 1 commit
  7. 13 Nov, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-11-13 12:21:08 by simonmar] · 351afa5a
      simonmar authored
      Add support for gcc-style "make bootstrap" which will build the stage
      1, 2 and 3 compilers in the same build tree.
      The idea is to simplify building a stage 2 or 3 compiler (now you only
      need one build tree), and also speed up the build: there's no need to
      compile the libraries more than once, because the stage 1 libraries
      are used for stages 2 & 3.
      In ghc/compiler, the objects and .hi files are now placed in
      subdirectories: ghc/compiler/stage1 has the stage1 objects,
      ghc/compiler/stage2 has the stage2 objects, etc.
      The story from the top-level (fptools) is this:
        make all 	  works as before (i.e. builds ghc (stage 1),
      		  libraries, etc.)
        make stage2     builds the stage 2 compiler
        make stage3     builds the stage 3 compiler
        make bootstrap  does 'make all' followed by 'make stage2'
        make bootstrap3 does 'make all' followed by 'make stage2; make stage3'
      In ghc/compiler, the story is now:
        make all	     works as before (i.e. builds stage 1 only)
        make boot          generate build dirs and dependencies for stage 1
        make boot stage=N  generate build dirs and dependencies for stage N
        make stageN
        make stage=N       builds stage N compiler.  Run it in-place using
      I haven't decided what to do about 'make install' yet, and this still
      needs documenting in the Building Guide.  Also, you still get the same
      $(GhcHcOpts) for each stage.
  8. 21 Jul, 2001 1 commit
  9. 04 Apr, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-04-04 13:39:09 by simonmar] · df7e4572
      simonmar authored
      Automatically re-generate and re-run configure as necessary.  This
      seems to be a reasonable thing to do, and it should eliminate a large
      class of "I ran cvs update and now I get this strange error" type of
      If anyone can remember why this might not be a good idea (I vaguely
      remember there being some reason but it escapes me now), please pipe
  10. 23 Mar, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-03-23 16:36:20 by simonmar] · 50027272
      simonmar authored
      Changes to support bootstrapping the compiler from .hc files.  It's
      not quite working yet, but it's not far off.
        - the biggest change is that any injected #includes are now placed in
          the .hc file at generation time, rather than compilation time.  I
          can't see any reason not to do this - it makes it clear by looking at
          the .hc file which files are being #included, it means one less
          temporary file at compilation time, and it means the .hc file is more
        - all the gruesomeness is in mk/bootstrap.mk, which handles building
          .hc files without a ghc driver.
  11. 13 Jan, 1998 1 commit
  12. 14 Mar, 1997 1 commit