Yes of course UTF8 text files should not use the BOM but
notepad.exe does anyway. Fixes ticket #533.

Fixes ticket #89. The library gets registered into an inplace
package db file which is used when building the executables.
Based partly on an original patch by Stephen Blackheath.

Since we have to be able to use these inplace we always need
the index it's not enough to just make the index on installing.
This particularly affects OSX.

Allow the user package db to appear after a specific one.
No reason not to and makes some things in cabal-install more convenient.

Part of #369

Just uses simplifyVersionRange on the version range in the dep

This lets us pass a whole stack of package databases to the compiler.
This is more flexible than passing just one and working out what
other dbs that implies. This also lets us us more than one specific
package db, which we need for the inplace package db use case.

Part of ticket #369. Now instead of:
  setup: At least the following dependencies are missing:
  base <3 && <4 && <3 && <3 && <4
we get:
  setup: At least the following dependencies are missing:
  base <3

Part of one of Stephen Blackheath's patches

Based on an original patch by Stephen Blackheath
With this change build-depends on a library within the same package
are detected. Such deps are not full handled yet so for the moment
they are explicitly banned, however this is another step towards
actually supporting such dependencies. In particular deps on
internal libs are resolved to the internal one in preference to any
existing external version of the same lib.

Based on an original patch by Stephen Blackheath
Previously each component got built using the union of all package
deps of all components in the entire package. Now we use exactly the
deps specified for that component. To prevent breaking old packages
that rely on the sloppy behaviour, package will only get the new
behaviour if they specify they need at least cabal-version: >= 1.7.1

Concrete XML syntax is used in the Haskell Server Pages extension 
language, and a description can be found in the paper "Haskell Server 
Pages through Dynamic Loading" by Niklas Broberg, published in Haskell 
Workshop '05.

Regular expression pattern matching is described in the paper "Regular 
Expression Patterns" by Niklas Broberg, Andreas Farre and Josef 
Svenningsson, published in ICFP '04.

The dynlibPref patch accidentally was only pushed to ghc's branch.

It will need more thought about how much control the user needs
and what the default shared libs management scheme should be.

So now when building, we actually use per-component set of package deps.
There's no actual change in behaviour yet as we're still setting each of
the componentPackageDeps to the union of all the package deps.

Not yet used

We generate this file if necessary when registering.

It doesn't need the entire PackageDescription

So it's now a bit clearer what is going on in the generic build code
Also shift info calls up to generic code

Take a Library/Executable rather than a PackageDescription
Means we're more precise in using it, just passing the info we need.

Some kind of shell script wrapper feature might be useful,
but we should design it properly.

It was an ugly hack and ghc no longer uses it.

We want to have each component have it's own dependencies,
rather than using the union of deps of the whole package.

The purpose of these tests is mostly to pin down some existing behaviour to
ensure it doesn't get broken by the ticket #89 changes.

This provides dependencies specifically for each library and executable target.
buildDepends is calculated as the union of the individual targetBuildDepends,
giving a result that's exactly equivalent to the old behaviour.

Eg now says something like:
cabal: Haddock's internal GHC version must match the configured GHC version.
The GHC version is 6.8.2 but haddock is using GHC version 6.10.1

haddock-2.x doesn't define any additional macros.