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.

That is the arch and os strings in conditionals in .cabal files, like:
  if arch(x86_64)
Previously the parser used isAlphaNum c || (c `elem` "_-"). This is
crucial for arch names like "x86_64". So make the new parser for OS
and Arch types use the same string parser as before (there is a string
parse part and a separate classification of known OS/Arch values).

Stops it barfing on arch(x86_64).

I think. It's hard to test since with base as it is we cannot
easily compile without that instance being in scope.

The pretty printer version should be using Text but I've left them as
comments for the moment as they do not have corresponding parsers yet.

One use was for parsing bools in the installed package info. We can
go with the more liberal Text instance for that. The other use is for
parsing Haskell strings in quoted string fields. So we keep it for
that purpose but restrict the type and rename to parseHaskellString.

So it accepts the same valid values as parseReadS did, but doesn't
fall over on unknown values, returning (OtherCompiler "the_name").