So it "Just Works"tm without needing extra options or sudo fiddling.
If you care you can still do sudo fiddling and --global-install

We can now install purely using cabal, no Makefile needed.
The install instrcutions previously said to install the data
file manually, but cabal does that for us now.

Fix the license, it's BSD3 not BSD4 (I double checked with Issac)
Have cabal install the serv.list for us as a data file.
Add HTTP and filepath as dependencies, rather than bundling them.

Enabled at -v2

So that at ordinary -v1 we do not get lots of silly warnings for outdated
.cabal files, like warnings about hs-src-dir vs hs-src-dirs.

This is relevant since we pass on this default verbosity when we call cabal,
so it's much better if they match up.

This should make it all "Just Work"tm. We no longer need a Makefile
to do the installation. The point is, don't bother trying to use
/etc/cabal-install/srve.list as the global list. That's hard to do
because it involves installing that file, and we only want to do that
for global installs, so it's even more complex. Instead we should just
use cabal's facility to install data files. That way it ends up in
/usr/local/share/cabal-install-x.y/
or somewhere similar for a user install. But either way, cabal handles it.
The per-user config sill overrides this one, so it's still possible to edit
the list even if /usr/local/share/ is read-only. Also, we always use
$HOME/.cabal-install/ for the per-user config and package cache.
The one downside is that if an admin wants to use /etc/ and /var rather
than /root/.cabal-install/ then this is a tad harder. But the point is
at the moment it'll at least work for most people without fiddling,
including windows users.

This is useful when you want to build a development version of something whose dependencies are available in Hackage. 

Before, getOpt would return a list of Flag, which had a one-to-one correspondence with functions TempFlags -> TempFlags. This made it uneccessarily difficult and error-prone to add new flags. I removed the Flag type and replaced the values with TempFlags -> TempFlags functions. This should have the side effect of making the tar path flag work, since it was not interpreted before.

See http://hackage.haskell.org/trac/ghc/ticket/3268
In new versions of ghc-pkg, ghc-pkg dump will emit an extra field like
pkgroot: /the/path/that/is/the/pkgroot
and other fields may contain ${pkgroot}, e.g.
library-dirs: ${pkgroot}/blah/
This allows relocatable packages, with package files installed
relative to the package database itself.

To allow parsers & pretty-printers for extensions of the format.

And add a TODO about future handling of OS variants like Android and iOS.

It has been deprecated in ghc-7.2
and ghc builds core libs with -Werror so we have to comply.

Otherwise we cannot use '{' '}' chars in field contents, as they
get interpreted as layout syntax. We want this for things like:
  library-dirs: ${pkgroot}/../libfoo/

Fixes ticket #844. Previously the function that merged the HookedBuildInfo
into the PackageDescription would add a library section even if none
previously existed.

Now we generate an error message if the HookedBuildInfo contains info
for non-existant components (libs/exes), e.g:

Setup: The buildinfo contains info for a library, but the package does not
have a library.

As suggested by Hamish Mackenzie

Hopefully should fix ghc ticket #4982.
The problem was permissions on directories: previously we used ordinary
createDirectory and on unix this creates dirs using the current user's
umask. If the root user has a silly umask then someone doing sudo
install will end up with dirs that are not readable by non-root users.

So the solution is to do the same as we do with files: override the
umask and explicitly set the file permissions based on the kind of
file: ordinary file, executable file and now also directory.

Sadly we also had to re-implement createDirectoryIfMissing to use our
new createDirectory wrapper function.

This patch adds intrapackage dependency resolution so that components
(libraries, exes, test suites) are build in the correct order.  This mean it's
now possible to have, e.g., executables that depend on other executables defined
in the same package description: the build-tools namespace has been extended
accordingly.
  
Related to this change is the refactoring of the do-it-all preprocessSources
function, formerly invoked by initialBuildSteps, into a a function
preprocessComponent that is invoked when a component is being built.  This lets
us use executables defined in a package to be used as a custom preprocessor when
building other components.
  
Finally, a number of functions now operate on values of the sum type
PackageDescription.Component rather than specifically operating on Library or
Executable and so forth.

That is, allow generating a dir tree rather than a tarball.
Apart from being useful directly, this is the right approach for
tools like cabal-install. cabal-install does the tar step itself
and might like to do other things like zip format.
Also cleaned up the sdist code a little.