GitLab

Moved GTK_CONFIG detection to ghc subdirectory (untested).

Pushed "ghc has readline" check down to ghc subdir

Add directories for ghc/lib & ghc/lib/compat

Get all project info from configure.ac

Ooops, forgot to rename version.mk in my previous committ...

Use version info from configure.ac

HEAD is now 6.3

Revert to previous commit, i.e. ProjectVersion is now a plain "6.1"
again, not "6.1.20030727". It looked like an accidental commit and
broke my build scripts.

Disable update-in-place.  In its current form, it has a serious bug:
if the thunk being updated happens to have turned into a BLACKHOLE_BQ,
then the mutable list will be corrupted by the update.

Disabling update-in-place has some performance implications: many
programs are not affected, but one program in nofib (nucleic2) goes
about 20% slower.  However, I can get it to go 300% faster by adding a
few strictness annotations and compiling with -funbox-strict-fields.

Remove ancient/bogus booting-from-hc stuff.

The HEAD is version 6.1 now.

Version 6.0

Remove obsolete references to DriFT, DtdToHaskell and Xtract.

fix ProjectVersion

Fix some bugs in compacting GC.

Bug 1: When threading the fields of an AP or PAP, we were grabbing the
info table of the function without unthreading it first.

Bug 2: eval_thunk_selector() might accidentally find itself in
to-space when going through indirections in a compacted generation.
We must check for this case and bale out if necessary.

Bug 3: This is somewhat more nasty.  When we have an AP or PAP that
points to a BCO, the layout info for the AP/PAP is in the BCO's
instruction array, which is two objects deep from the AP/PAP itself.
The trouble is, during compacting GC, we can only safely look one
object deep from the current object, because pointers from objects any
deeper might have been already updated to point to their final
destinations.

The solution is to put the arity and bitmap info for a BCO into the
BCO object itself.  This means BCOs become variable-length, which is a
slight annoyance, but it also means that looking up the arity/bitmap
is quicker.  There is a slight reduction in complexity in the byte
code generator due to not having to stuff the bitmap at the front of
the instruction stream.

Duh.  hsc2hs should be in $(GhcBinDistShScripts), not
$(GhcBinDistBins), otherwise it doesn't get the right directories
tacked on the front at installation time.  Strange that nobody
complained that hsc2hs wasn't working from a binary dist *shrug*.

Merge the eval-apply-branch on to the HEAD
------------------------------------------

This is a change to GHC's evaluation model in order to ultimately make
GHC more portable and to reduce complexity in some areas.

At some point we'll update the commentary to describe the new state of
the RTS.  Pending that, the highlights of this change are:

  - No more Su.  The Su register is gone, update frames are one
    word smaller.

  - Slow-entry points and arg checks are gone.  Unknown function calls
    are handled by automatically-generated RTS entry points (AutoApply.hc,
    generated by the program in utils/genapply).

  - The stack layout is stricter: there are no "pending arguments" on
    the stack any more, the stack is always strictly a sequence of
    stack frames.

    This means that there's no need for LOOKS_LIKE_GHC_INFO() or
    LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
    how to find the boundary between the text and data segments (BIG WIN!).

  - A couple of nasty hacks in the mangler caused by the neet to
    identify closure ptrs vs. info tables have gone away.

  - Info tables are a bit more complicated.  See InfoTables.h for the
    details.

  - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
    in GHCi which affected primitives and unboxed tuples are now
    fixed.

  - Binary sizes are reduced by about 7% on x86.  Performance is roughly
    similar, some programs get faster while some get slower.  I've seen
    GHCi perform worse on some examples, but haven't investigated
    further yet (GHCi performance *should* be about the same or better
    in theory).

  - Internally the code generator is rather better organised.  I've moved
    info-table generation from the NCG into the main codeGen where it is
    shared with the C back-end; info tables are now emitted as arrays
    of words in both back-ends.  The NCG is one step closer to being able
    to support profiling.

This has all been fairly thoroughly tested, but no doubt I've messed
up the commit in some way.

$(EXE_SUFFIX) duplicates $(exeext), and the latter seems to be more
widely used, so nuke the former.

Added GHC_MANGLER_DIR, GHC_SPLIT_DIR + fix .raw_s -> .s bootstrap suffix rule

HEAD is now 5.05

5.04

Remove $(GhcBinDistDocs), this will be done differently

Use hasktags for the HSTAGS_PGM

add libraries to BinDistDirs

Switch over to the new hierarchical libraries
---------------------------------------------

This commit reorganises our libraries to use the new hierarchical
module namespace extension.

The basic story is this:

   - fptools/libraries contains the new hierarchical libraries.
     Everything in here is "clean", i.e. most deprecated stuff has
     been removed.

	- fptools/libraries/base is the new base package
	  (replacing "std") and contains roughly what was previously
	  in std, lang, and concurrent, minus deprecated stuff.
	  Things that are *not allowed* in libraries/base include:
		Addr, ForeignObj, ByteArray, MutableByteArray,
		_casm_, _ccall_, ``'', PrimIO

	  For ByteArrays and MutableByteArrays we use UArray and
	  STUArray/IOUArray respectively now.

	  Modules previously called PrelFoo are now under
	  fptools/libraries/GHC.  eg. PrelBase is now GHC.Base.

	- fptools/libraries/haskell98 provides the Haskell 98 std.
	  libraries (Char, IO, Numeric etc.) as a package.  This
	  package is enabled by default.

	- fptools/libraries/network is a rearranged version of
	  the existing net package (the old package net is still
	  available; see below).

	- Other packages will migrate to fptools/libraries in
	  due course.

     NB. you need to checkout fptools/libraries as well as
     fptools/hslibs now.  The nightly build scripts will need to be
     tweaked.

   - fptools/hslibs still contains (almost) the same stuff as before.
     Where libraries have moved into the new hierarchy, the hslibs
     version contains a "stub" that just re-exports the new version.
     The idea is that code will gradually migrate from fptools/hslibs
     into fptools/libraries as it gets cleaned up, and in a version or
     two we can remove the old packages altogether.

   - I've taken the opportunity to make some changes to the build
     system, ripping out the old hslibs Makefile stuff from
     mk/target.mk; the new package building Makefile code is in
     mk/package.mk (auto-included from mk/target.mk).

     The main improvement is that packages now register themselves at
     make boot time using ghc-pkg, and the monolithic package.conf
     in ghc/driver is gone.

     I've updated the standard packages but haven't tested win32,
     graphics, xlib, object-io, or OpenGL yet.  The Makefiles in
     these packages may need some further tweaks, and they'll need
     pkg.conf.in files added.

   - Unfortunately all this rearrangement meant I had to bump the
     interface-file version and create a bunch of .hi-boot-6 files :-(

Add ProjectPatchLevel

Better off if GhcBinDistShScripts is just empty on mingw plats

oops, revert accidental commit

good riddance

Remove the "extra-bin" subdirectory from $(libexecdir), since there
are too many assumptions in the tree that $(libexecdir) == $(libdir)
(at the moment, binary dists are fairly well broken).

Reuben has promised to track the change in the Windows distribution.

Advance HEAD version to 5.03.

GHC_INTERPRETER_DIR is unused

Binaries now live in extra-bin

Changes to nuke RAWCPP.

include version.mk before boilerplate.mk, so that boilerplate.mk has
the project name and version available.

Override libdir and datadir in fptools/mk/config.mk to add the project
name and version.

Suggested by: Manuel

use xcopy, as copy is a cmd.exe built-in

override $(libexecdir) to be $(libdir)/bin (the installation machinery
will have to catch up with this too).

fix typo in Simon's commit (cGHC_RAWCPP ==> GHC_RAWCPP)

----------------------
	Installation packaging
	----------------------

GHC runs various system programs like
	cp, touch
	gcc, as, ld etc

On Windows we plan to deliver these programs along with GHC,
so we have to be careful about where to find them.

This commit isolates all these dependencies in a single module

	main/SysTools.lhs

Most of the #ifdefery for mingw has moved into this module.
There's some documentation in SysTools.lhs

Along the way I did lots of other cleanups.  In particular

  * There is no more 'globbing' needed when calling runSomething
  * All file removal goes via the standard Directory.removeFile
  * TmpFiles.hs has gone; absorbed into SysTools
  * Some DynFlag stuff has moved from DriverFlags to CmdLineOpts


Still to do:

  **	I'm a bit concerned that calling removeFile one at a time
	when deleting masses of split-object files is going to be
	rather slow

  **	GHC now expects to find split,mangle,unlit in
		libdir/extra-bin
	instead of just
		libdir

	So something needs to change in the Unix installation scripts

  **    The "ineffective C preprocessor" is a perversion and should die