Spotted by the testsuite which I'm trying to resurrect.

Changing from list of Dependencies to Maps resulted in the wrong Monoid 
instance being used.  I'd still like to be able to run a test suite on 
this but that'd require a lot more work to do properly...

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.

We already do this for error messages.

Previously we rejected all such flags but that posed the problem that older
versions of Cabal, like 1.1.6 did not understand new extensions so we
could not actually follow the advice and use the extenion. So now we only
warn about -X flags if they refer to old extensions that Cabal 1.1.6 knew
about. If the .cabal file specifies cabal-version: >= 1.2 or similar
(anything that excludes 1.1.6) then we warn about all -X flags.

They're ok locally but for distribution they need to be known.

Unfortunately in some cases we only have a already-configured
PackageDescription to we have to expose a checkConfiguredPackage.
We should refactor things so that we keep all the information
even in a configured PackageDescription.

Some code and test cases taken from the utf8-string package.
Updated copyright notice appropriately (I think).

It's possible that we sometimes need to list the same library
more than once if there are circular symbol references.

Fix ticket #264 to use nub only on the fields which are treated as sets.
Probably we should be using the right types and mappend for each field.
Change to construct a new value from scratch rather than overriding one
of the two args. This helps to make sure we're updating all the field
as we get a warning if we miss any. Turns out we were missing the ghc
profiling and shared libs options which meant they were getting dropped.
That had the effect of ghc-prof-options: in .cabal files being ignored.
Thanks to 'midfield' from #haskell for spotting this.

and use them in the appropriate places.

Packages in the second argument to merge now mask those in the first.

Use the proper data type rather than a tuple (CompilerFlavor, Version)

did not occur in the package (it is just silently ignored.)

go into the test suite one day.

There were two reasons to do this.  Firstly, this formulation makes it
easier to add the --constraint command line flag that adds additional
constraints on the packages that should be used.

Secondly, with the orgininal algorithm it was possible to satisfy the
constraint "foo < 1, foo > 2" if we had two versions of package "foo"
which each satisfy one constraint.  This patch fixes this by requiring
the same package to satisfy both constraints (which of course is
impossible in this case).

This helps finding the options to pass to GHC API in various tools

This is needed by Yi to (try to) load an arbitrary
project.

Previously we only checked the "cabal-version" field after parsing
and all other configure processing. If the package really needs a
later Cabal version it is of course highly likely that parsing or
configure are going to fail and the user is not going to get the
helpful error message about the version of Cabal required. So now
we do the check early during parsing. If a later version is
required and parsing subsequently fails, we now report the version
issue, not the subsequent parse error. If parsing succeeds we
still issue a warning which should be a useful hint to the user if
subsequent configure processing fails.

Do this by normalising the file path in the error message
and when looking for .cabal files, by looking in '.' rather
than the absolute path of the current directory.

Which happened if you use cabal configure in your home dir.
Now produced the right error message, or if you actually put
a cabal project in your home dir, it might actually work.
Also, do the same fix for findHookedPackageDesc.

I broke this recently when refactoring. Restore the original behaviour.
Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a".

Though we should try and limit divergence until 1.4.0 is released.

Warning: The 'buildable' field is case sensitive, use 'True' or 'False'.

It's a bit more consistent.

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.

Since it exactly matches what the previous condition parser did.
So we have two different ways of parsing Bool depending on
context. Sigh. Both match exactly what was done in Cabal-1.2.

We want to allow case-insensitive parsing however we don't want
packages being uploaded to hackage that will break older versions of
Cabal. If we allow new valid parses then we will end up breaking
stuff. So what we really want to do is allow new parses but warn if
they're not ones that older versions of Cabal would have allowed. So
long as hackage rejects pakcages that have parse warnings then we can
prevent new .cabal files appearing on hackage that would break older
Cabal versions. Our current parser (ReadP) does not support warnings
so we have to handle the bool fields specially in the parser wrapper
layer that we added to handle errors and warnings. This can go away
when we use a parser with support for error and warning messages.

So far just a test that all the non-trivial Setup.(l)hs scripts
compile. This only tests the latest versions, though if one were
to download a complete archive then one could test them all.
To speed up the check we skip Setup.hs scripts that have fewer
than 22 words. Below this cutoff there are no custom hooks and
it catches the great majority of scripts which greatly speeds up
the check.

Despite appearances this is actually not completely pointless.
For the Cabal-1.4 branch we need the *Verbose fields to have the
same types as they did in Cabal-1.2, becuase lots of Setup.hs
scripts use them and our change to make them all have type Flag
makes many Setup.hs scripts fail. A solution for the 1.4 branch
is to rename the real field and to add the old field back in.
To keep as much similarity as possible between the HEAD and 1.4
branches I'm applying the name change in both.
On the plus side it's a better name anyway.

Previously we checked for invalid UTF-8 in the first phase of the
parser, which splitting the file up into nested sections and fields.
This meant the whole parser falls over if there is invalid UTF-8
anywhere in the file. Sadly there are already packages on hackage
with invalid UTF-8 so we would fail when parsing the hackage index.
The solution is to move the check into the parsing of the individual
fields and making it a warning not an error. We most typically get
invalid UTF-8 in free text fields like author name, copyright,
description etc so this should work out ok usually.
We now get pretty decent error messages, like:
  Warning: hsx.cabal:5: Invalid UTF-8 text in the 'author' field.
The warning type is now structured so that hackage will be able to
distinguish general non-fatal warnings from UTF-8 decoding problems
which really should be fatal errors for package uploads. 

We have to classify System.Info.{os,arch} strings into the OS and Arch
enums. For that purpose we have to be quite permissive since there are
lots of ailases that the various Haskell implementations use. However
for parsing os and arch names in .cabal files we'd prefer to use
canonical names, though we do have to allow the couple aliases already
in common use.