this is so that the stage1 compiler has proper support for Unicode.
Should fix these errors:

  lexical error in string/character literal at character '\8759'

when building the stage2 compiler.

Avoid building the GHCi version of this lib

Never use an installed Cabal package when building GHC (except when
bootstrapping in stages 2 & 3).  This insulates us from changes the
user may have made to their Cabal installation.

Add explicit dependency for Distribution.Compat.FilePath

Add Distribution.Compat.FilePath to the relevant places.

split Distribution.Extension between Language.Haskell.Extension (just
the type, which will also be useful when haskell-src-exts is merged)
and Distribution.Compiler (mappings to compiler options).

Use -optdep--exclude-module to fix building HEAD with itself.

refactoring only: split Compiler type from Distribution.Setup,
to reduce dependencies.

Add -I options to SRC_CC_OPTS for bootstrapping

From: Thomas Schwinge

Don't split in here

make 'mkdependC' happy

[Windows only]
for System.Directory / Compat.Directory functionality that probes the OS
for local details re: misc user directories, perform late binding of
SHGetFolderPath() from shell32.dll, as it may not be present.
(cf. ghc-6.4's failure to operate on Win9x / NT boxes.) If the API isn't
there, fail with UnsupportedOperation.
Packages.readPackageConfigs: gracefully handle excns from getAppUserDataDirectory.

Merge to STABLE.

NO_INSTALL_LIBRARY=YES

Need to add -I. when compiling with GHC 6.3+

Futher gruesome makefile hackery to deal with building lib/compat

Compile utilities and lib/compat with GhcHcOpts, in case it is profiled

Common up the ghc_ge_XXX variables into config.mk, and add the
ability to build ghc/lib and ghc/utils using the stage1 compiler, by
saying 'make UseStage1=YES'.  This is going to be useful for
bootstrapping.

Remove System.FilePath, use System.Directory.Internals for now.

Dynamic Linking, Part 2:

Hack the Makefiles to build dynamic libraries.
This allows you to actually use dynamic libraries to greatly reduce binary
sizes on Darwin/PowerPC and on powerpc64-linux (for now).

To use this, add the following to your build.mk

SplitObjs=NO
GhcBuildDylibs=YES
GhcStage2HcOpts=-dynamic
GhcLibHcOpts+=-fPIC -dynamic
GhcRtsHcOpts+=-fPIC -dynamic
GHC_CC_OPTS+=-fPIC

(You can leave out the last three lines on powerpc64-linux).

Then, to compile a program using dynamic libraries, pass the -dynamic option to GHC.
To make GHCi use the dynamic libraries instead of .o files, just delete the HS*.o files.

The dynamic library files are named libHSfoo_dyn.dylib or libHSfoo_dyn.so.

Note that the dynamic and static libraries are build from the same .o files,
but we really want to build the static libraries with SplitObjs and without
-fPIC -dynamic to achieve better code size and performance.

ghc/compiler/ghci/Linker.lhs:
    When looking for a library, look for HSfoo.o first (as before),
    then look for libHSfoo_dyn.[so/dylib] before looking for
    libHSfoo.[so/dylib].

ghc/compiler/main/DriverPipeline.hs:
    Main.dll_o and PrelMain.dll_o are dead, at least for now.

ghc/compiler/main/Packages.lhs:
    When -dynamic is specified, add "_dyn" to all libraries specified in
    hs-libraries (not to the extra-libs).

ghc/lib/compat/Makefile:
    Never build libghccompat as a dynamic lib.

mk/package.mk:
    if GhcBuildDylibs is set to YES, build dynamic libraries.

mk/target.mk:
    When installing .dylibs (Darwin only), update the install_name to point
    to the final location.
    (Somebody please read Apple's documentation on what install_names are,
    and then comment on whether this is a useful feature or whether it should
    be done the "normal" unix way).

Track removal of Distribution.Compat.Error.

Add Distribution.Compat to libghccompat

Data.Version isn't necessary any more, the Version type is exported by
Distribution.Version.

Further integration with the new package story.  GHC now supports
pretty much everything in the package proposal.

  - GHC now works in terms of PackageIds (<pkg>-<version>) rather than
    just package names.  You can still specify package names without
    versions on the command line, as long as the name is unambiguous.

  - GHC understands hidden/exposed modules in a package, and will refuse
    to import a hidden module.  Also, the hidden/eposed status of packages
    is taken into account.

  - I had to remove the old package syntax from ghc-pkg, backwards
    compatibility isn't really practical.

  - All the package.conf.in files have been rewritten in the new syntax,
    and contain a complete list of modules in the package.  I've set all
    the versions to 1.0 for now - please check your package(s) and fix the
    version number & other info appropriately.

  - New options:

	-hide-package P    sets the expose flag on package P to False
	-ignore-package P  unregisters P for this compilation

	For comparison, -package P sets the expose flag on package P
        to True, and also causes P to be linked in eagerly.

        -package-name is no longer officially supported.  Unofficially, it's
	a synonym for -ignore-package, which has more or less the same effect
	as -package-name used to.

	Note that a package may be hidden and yet still be linked into
	the program, by virtue of being a dependency of some other package.
	To completely remove a package from the compiler's internal database,
        use -ignore-package.

	The compiler will complain if any two packages in the
        transitive closure of exposed packages contain the same
        module.

	You *must* use -ignore-package P when compiling modules for
        package P, if package P (or an older version of P) is already
        registered.  The compiler will helpfully complain if you don't.
	The fptools build system does this.

   - Note: the Cabal library won't work yet.  It still thinks GHC uses
     the old package config syntax.

Internal changes/cleanups:

   - The ModuleName type has gone away.  Modules are now just (a
     newtype of) FastStrings, and don't contain any package information.
     All the package-related knowledge is in DynFlags, which is passed
     down to where it is needed.

   - DynFlags manipulation has been cleaned up somewhat: there are no
     global variables holding DynFlags any more, instead the DynFlags
     are passed around properly.

   - There are a few less global variables in GHC.  Lots more are
     scheduled for removal.

   - -i is now a dynamic flag, as are all the package-related flags (but
     using them in {-# OPTIONS #-} is Officially Not Recommended).

   - make -j now appears to work under fptools/libraries/.  Probably
     wouldn't take much to get it working for a whole build.

Needed to include a header file in Compat/Directory on windows

Need to add System to ALL_DIRS

* Add stub for System.FilePath
* Add findExecutable & copyFile to Compat.Directory

Add a more prominent description of what this library is all about.

- include cbits dir
- omit certain libraries when ghc > 6.2
- build this library at boot-time, because it will be needed by ghc-pkg

Move the compatibility code for rawSystem from libraries/base into
ghc/lib/compat.

Add a compatibility library, which will mean that we can make use of
brand new libraries directly in GHC and the tools even when compiling
with older versions of GHC.  The library just consists of stubs that
#include code from fptools/libraries.

This isn't wired up to the build yet.