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

Slightly more like full sentances and using '' quotes for field names etc.

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.

and simplfy the implementation to be a simple composition of
findFileWithExtension' and copyFiles with some additonal error checking.

This was the old module using it in with preserveDirs = True.
Anyway, we should be using smartCopySources for each lib and exe, we should be
collecting all the files to copy together into one list, then eliminating
duplicates and doing a single copyFiles operation. Yes, there can be
duplicates because for example exes can specify the libbrary's modules or 
even the other exe's main module as other-modules.

otherwise we fail to copy the .cabal file when into the src tree

The remaining Bool parameter is False for all uses except in SrcDirs

which we have removed support for. It is not clear if we need any similar
handling for .hs-boot files. These were also the only uses of smartCopySources
which used exitIfNone set to False.

Previously it used moduleToFilePath2 which returns all the locations in which
a source file is found, in different search dirs and with different extensions
and it just collected all these locations. This is totally bogus since we do
not want to copy multiple source files per-module, only one of them could have
been used to be pre-processed into the final source module. This is one
example of how almost every use of moduleToFilePath is convoluted or broken.
This function it still used for too many different purposes, witness the two
flags to customise its behaviour which at all call sites are constants.

and rewrite findFile in a similar style. These are to help simplify and
replace the existing functions smartCopySources, moduleToFilePath and
moduleToFilePath2.

Follow the H98 report and replace ">" with " " not "".
Output the whitespace for blank lines rather than "".
Adjust to changes in unlit error handling, now more explicit.

And to make it more like the original code that classified lines
separately from checking and transforming them.

unlit preserves comments for Haddock's benefit. More complex algorithm to handle cases where we want blank lines (containing whitespace) to become comment lines in the output.

and a couple other trivial tidyups

I doubt it works or that anyone uses it.
If anyone genuinely does use it we can add it back in cabal-install.

It used to look for and warn about Setup.description files.
That's from a very very old transition which is now complete.
We can just ignore any files like that now.

Should allow satisfying deps from the given package db and should register
into that db. It is not thoroughly tested however.

Added a check for the existence of the license file (if one is
specified in a license-file: field) during description file
sanity checking.  If a license is specified but does not exist,
a warning is generated.  This patch resolves issue #180.

Though of course we cannot yet change the UserHooks interface so that it is
never given the LocalBuildInfo.

There was only one use and no point since rawSystem uses the path anyway.

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

make it a .hs like everyone else uses

and jhc should just be putting its generated files under dist/ anyway.
The latter issue is filed as bug #219.

Saves printing an error message when it fails.

So it doesn't use a temp file to capture the output.
Since runInteractiveProcess is only available on ghc we
use the temp file method for other implementations.

Many Setup.hs files import Distribution.Setup so this unbreaks them.
It's marked DEPRECATED so will generate a warning for scripts that use it.
This patch is only going to the cabal-1.2 branch, not HEAD.

to $HOME/.cabal on unix and on WinXP: (not sure about vista)
C:\Documents And Settings\user\Application Data\cabal

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

The System.IO.openTempFile is much better because it opens the temp files
securely. Howver it is only available in base-2 and only of GHC. In base-3
it is available for all implementations. So in practice that means it's only
for GHC and we have to use our compatability implementation for hugs and
nhc98. Not sure of the status for jhc.