Apply $libdir hack to GHCi libs in the same way as ordinary .a libs.

Fixed the previous commit: All lists of Strings in package configuration files
were split at commas to allow list-based variables, but this broke perfectly
sensible things like

   ["-Wl,-rpath,/usr/lib/jvm-bridge/lib/"]

into

   ["-Wl","-rpath","/usr/lib/jvm-bridge/lib/"]

which is plainly wrong. Now we do this *only* when a variable occurs on its own,
like:

   ["${deps}","foo"] => ["base","haskell98","network","foo"]

I have slight doubts about this obscure feature, but Sigbjorn seems to want
it...

Merge to STABLE

expandEnvVars.expandStrings: flatten the expanded strings so as to
permit a substitution to expand into multiple elements of the final
list.

merge to stable.

Teach ghc-pkg the now standard -?/-V options

New option, -DNAME=VAL, for adding to the set of
variables substituted for when processing a package
description.

(Needed to support Windows installers for GHC packages.)

expandEnvVars.expandString: don't drop prefix when locating variable
reference.

Merge to STABLE.

Rename --list-packages-local to --list-local-packages, because it
seems that having one long option which is a prefix of another doesn't
work too well with GetOpt.

Add -L (--list-packages-local) flag which lists packages in the
topmost configuration file only.

Handle multiple config files correctly.  Now it is possible to specify
a dependency on a package in another config file, and --list-packages
lists all the packages in each file.

The last file mentioned on the command line is the one to which
updates are applied, packages are added, etc.

Slight tidy up

Make imports work for pre-504

Remove Win32 library dependency.

Make ghc-pkg independent of hslibs

Build without hslibs on GHC >= 5.04

GHCi lib autogeneration for MacOS X

Added support for Frameworks on MacOS X.
*) On MacOS X, two additional command-line options are supported:
-framework <FRAMEWORK>    link with framework, gets passed on to ld
-framework-path <PATH>    gets passed on to ld as "-F<PATH>". (-F is already taken for GHC).
*) Two corresponding additional options for package.conf files:
framework_dirs
extra_frameworks
These options are allowed on any platform. They are ignored everywhere except on MacOS X.
*) ghc-pkg no longer uses Read. Instead, it uses a Happy parser. ghc/utils/ghc-pkg/ParsePkgConfLite.y is basically a copy of ghc/compiler/main/ParsePkgConf.y. "Light" refers to the fact that it doesn't depend on other GHC modules and has less sophisticated error reporting.
*) Frameworks will need some additional work for GHCi.

Fix buglet with --force, spotted by George Russell

Use HOSTPLATFORM / *_HOST_OS (instead of TARGET equivalents), as we're
dealing with host-specific properties, not that of the target.

Add a --force option to ignore errors about missing directories and libraries.

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 :-(

Provide support for authors that want to distribute packages, by
expanding occurrences of "${foo}" in an input package spec with
the value of the 'foo' environment variable. This permits easy
configuration at install-time, e.g.,

  $ libdir=/opt/haskell/packages/lib ghc-pkg -a < NewPackage.pkg

[Clearly, a separate preprocessing pass using some other tool could
 provide identical functionality. However, the benefits to the
 package author of not having to depend on such a tool being present
 on a user's box was considered more important.
]

new option: -u / --update-package

New option, -i <file> / --input-file=<file>, which controls
where to read new package specs from. If <file> is equal to
"-", stdin is used as input source. The default value for
<file> is "-".

savePackageConfig: Robustified - remove existing .old file before saving
away new. In case of failure, print out a msg detailing what files were
involved.

- Add some sanity checking to --add-package: it won't accept a package
  config that refers to directories that don't exist, and it will
  check for the existence of the Haskell libraries.

- Automatically generate the GHCi .o versions of the .a libs, if the
  --auto-ghci-libs option is given (otherwise, just warn about their
  non-existence).

Go back to using a relative path name for the config.h include.
This is for the same reason that we do so in ghc/compiler/*, which
is that saying -I$(GHC_INCLUDE_DIR) confuses 4.08 series compilers.

Fix include of config.h

Fix ghc-pkg to find package.conf when installed on Windows

Allow multiple -f/--config-file options, taking the last one.  This
allows ghc-pkg to be used to modify a user-specified package.conf file.

Make ghc-pkg find its path on Windows

Don't use exitWith where exceptions are treated as errors.

Append final newline to package.conf.

- add --show-package option to display the config info for a particular
  package.

- add --field info, for use with --show-package, which displays the
  contents of the given field in the package config only.  The field
  is displayed one string per line.

- add ghc-pkg-$(ProjectVersion) and ghc-pkg-inplace scripts
- add ghc-pkg script link
- rename ghc-pkg to ghc-pkg.bin and put it in $(libdir)
- remove the hacky passing of $(libdir) to the binary

Preprocessing hack made less ugly by moving 'tail' from usage to definition.

OK, here comes the third try to get a simple string from the Makefile
into the Haskell sources in a "portable" way... Perhaps we should use
compiler/main/Config.hs's technique here.

Fix passing library dir to ghc-pkg.

play quoting games to hopefully get this to build with both ghc-4.08.2
and ghc-4.11+.

remove bogus import

New package management tool, basically a broken-out version of ghc
--list-packages, --add-package and --remove-package.

These flags will be removed from GHC; use ghc-pkg instead.