Since it is shared between libs and exes. Extend the documentation
to describe the syntax of version constraints, including the new
version range syntax "build-depends: foo ==1.2.*".

Change to runhaskell Setup or cabal-install as appropriate.

It doesn't need to be right up near the top.

in one of the fields exposed-modules, other-modules or main-is
Add an extra note to the section on the Paths_pkgname module
as the fact that it's automatically generated confuses people.

I realised when I started to document it that the behaviour
was not terribly consistent or sensible. The meaning now is:
  The limitation is that * wildcards are only allowed in
  place of the file name, not in the directory name or
  file extension. In particular, wildcards do not include
  directories contents recursively. Furthermore, if a
  wildcard is used it must be used with an extension, so
  "data-files: data/*" is not allowed. When matching a
  wildcard plus extension, a file's full extension must
  match exactly, so "*.gz" matches "foo.gz" but not
  "foo.tar.gz".
The reason for providing only a very limited form of wildcard
is to concisely express the common case of a large number of
related files of the same file type without making it too easy
to accidentally include unwanted files.

Fixes ticket #312. For example a user could use:
  cabal configure --libsubdir="$pkgid/$compiler/$arch"
if they wanted to have packages for multiple architectures
co-exist in the same filestore area.

Rather than "pkg ~ 1.2.*". This seemed to be the consensus.
The syntax "pkg == 1.2.*" means "pkg >= 1.2 && < 1.3" and it
is to encourage people to put upper bounds on api versions.

Should eliminate the corner case where we're doing a global
install but the user package db contains the exact same
version as in the global package db. Perhaps we should warn
in that case anyway since it's likely to go wrong later.

Since we do not need to know if hsc2hs uses ghc or gcc as cc
by default since in either case we now tell it to use gcc.

Lookup what flags to use from the package index. Previously this
was done by calling ghc as cc and passing -package flags to ghc.
ghc would then lookup what extra flags to pass to gcc. We now do
that ourselves directly and it's a good deal simpler and it's
portable to the other haskell implementations. This is only a
first go, the flags may not all be exactly right. Needs testing.

on Windows we have to find ghc's private copy of gcc.exe

with type :: PackageFixedDeps pkg => PackageSet pkg -> [pkg]

dependencyGraph and reverseDependencyClosure now return the
full package rather than just the PackageIdentifier

Turns out the feature to do case-insensitive lookups was only
needed in cabal-install (and only in one little part) and
elsewhere it causes problems. So use PackageSet instead.

This is a bit of a kludge around GHC's #2201, until Cabal is updated to
use ghc-pkg dump.

We used to do this with $(eval ...) and $(call ...) in the
Makefile, but make 3.79.1 (which is what comes with msys)
doesn't understand $(eval ...), so now we just stick the
expanded loop directly into the Makefile we generate.

if we have been told to use a specific one with --package-db

If datadir is foo and the datafile is bar then we should install it to
$datadir/bar, not $datadir/foo/bar.

a request from Saizan

When a preprocessor generates a .hs file we need to put the .hs-boot
file next to it so that GHC can find it.