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.
…P private 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.
* markup fixes * spelling * id's for some elements to avoid warnings * mention the use of Description field by setup haddock * clean up --hoogle description
It turns out that the cabal02 test is testing cabal-setup, so it helps to actually have it built.
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.
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)