This is an unpleasent way of doing it.
Will have to fix once and for all in the next version.

This change was added for ghc-6.6 but broke packages for ghc-6.2.2.

This is more normal.

In particular this means we pick up any cc-options that are
needed for preprocessing the source before haddock reads it.
This fixes the haddock build step for many of the packages in
the ghc-extralibs collection.

Ideally all the Distribution.Compat.* modules would be private,
however there is currently no sensible alternative to the FilePath module
and hiding it at this stage breaks packages.

ghc has supported --numeric-version for ages.

So it now works if you say:
./setup configure --with-compiler=ghc-6.5
ie specifying a path-relative name rather than an absolute path.
We then look for hc-pkg in the same dir as where we found the compiler.
If the compiler appears to have a version suffix then we additionally
and preferentially look for hc-pkg with that same version suffix.
(I'm not sure that bit works if you've got a .exe suffix, perhaps a
windows person could try it / take a look)

 * markup fixes
 * spelling
 * id's for some elements to avoid warnings
 * mention the use of Description field by setup haddock
 * clean up --hoogle description

Cabal was not noticing haddock failing. That's bad.

The newer cabal-install has different and fewer deps.
We will add those in for a release including cabal-install.

It just makes us look bad! :-)

It was using constant strings like "lib/ghc-6.4.1/blah"
which obviously doesn't work very well with ghc-6.5.20060903
Also let the test to run be specified on the command line to
make it easier to re-run individual tests.

Since we're not shipping cabal-install or cabal-setup just yet.