And update the changelog.
There should be no incompatible API changes or incompatible
behaviour changes. There are a number of compatible API extensions
and behaviour fixes. In particular this gives us a limited amount of
forward compatabilty with Cabal-1.4, ie there are things that work
in 1.4 that would break with 1.2.3.0 but should work with 1.2.4.0.

Required an extra util function.

Also add a package sanity check that main-is must specify a .hs or .lhs file.
So the bahaviour is now that main-is specifies the main source file, even if
that is generated by a pre-processor. This isn't really a change in behaviour
since previously if you specified main-is: main.hsc then it would try to
pass the .hsc file to ghc dirctly which would not work. For ticket #14 things
were fixed to that it would look for main.hsc if you used main-is: main.hs an
that file did not exist directy. This completes the other half, of actually
being able to make a src distribution. So this should fix bug #217.
Note that this still needs some work, we do not run platform-independent
preprocessors and put the result into the tarball for main-is files.
Generally, main-is has been the second class citizen compared to normal
modules. We should try and refactor so both use the same code paths.

eg if you had:
extensions: Foo
extensions: Bar, Baz
then previously we only ended up with [Bar, Baz]. Now we get them all.
Only applies to list fields, for single fields the second value is taken
and the first is silently discarded. This isn't good of course but the
fix is harder since we're not in a context where we can report errors.
Really we should just declare up front what kind of field it is and
inherit the right behaviour automagically, either duplicates disallowed
or allowed and combined with mappend.

Drop the trailing ": " on the error message. We could provide the field
value but they're often multi-line and we cannot pin-point where the
error is exactly.

This GetOpt patch was sent the the libraries list by Eelis van der Weegen
with the explanation:
There is a bug in System.Console.GetOpt causing it to mistakenly reject
options as ambiguous. Example:
  optsDesc = [Option "" ["color", "colour"] (ReqArg id "color") ""]
Output:
  option `--col' is ambiguous; could be one of:
      --color=color, --colour=color  Foreground color
      --color=color, --colour=color  Foreground color
This error is silly, because the two alternatives listed are the same option.

not defaultMainWithHooks defaultUserHooks since the latter is deprecated

and note the issue about custom vs simple build-type for Cabal itself.

so they are almost certainly useless to the debian folks anyway.

make it a .hs like everyone else uses

This is needed to separate Cabal and subprogram output if stdout is
buffered (e.g. a file), especially if stdout and stderr are the same.

Fixes ticket #11. Though the section could do with a bit more detail.
It corresponds to what's on the wiki:
http://hackage.haskell.org/trac/hackage/wiki/StableInterfaces

Fixed:
http://hackage.haskell.org/trac/hackage/ticket/176

Spotted by Spencer Janssen

for compatability with ghc-6.2.2

Rather than for every module in the lib. Tidy the code up a little too.

Supported in HsColour 1.9 and later

Should fixe reported wierdness with finding program version numbers

Cabal can now build using itself and nhc98

Andrea Vezzosi <sanzhiyan@gmail.com>**20080318161237
 Using readFile to read dist/setup-config keeps the Handle open when we try to delete the file, causing an error. 
  So we instead read the file strictly and close the Handle early.

There was one minor api addition which requires the minor version bump

Besides pre-processing, this patch adds include paths and output paths
to the ghc flags passed to Hadddock.