GitLab

eg we have build-tools like "pg_config"

     so that it really represents an option and not just a flag.
     It's been renamed to OptionField as it models a field in a flags-like data structure. 
     
        data OptionField a = OptionField {
          optionName        :: Name,
          optionDescr       :: [OptDescr a] }
      
        data OptDescr a  = ReqArg Description OptFlags ArgDescr (ReadE (a->a))         (a -> [String])
                         | OptArg Description OptFlags ArgDescr (ReadE (a->a)) (a->a)  (a -> [Maybe String])
                         | ChoiceOpt [(Description, OptFlags, a->a, a -> Bool)]
			 | BoolOpt Description OptFlags{-True-} OptFlags{-False-} (Bool -> a -> a) (a -> Bool)
      
      An option field can expand to several command line options, which are all defined together.
      For example, the compiler flag is defined as follows.
      
            option [] ["compiler"] "compiler"
               configHcFlavor (\v flags -> flags { configHcFlavor = v })
               (choiceOpt [ (Flag GHC, ("g", ["ghc"]), "compile with GHC")
                          , (Flag NHC, ([] , ["nhc98"]), "compile with NHC")
                          , (Flag JHC, ([] , ["jhc"]), "compile with JHC")
                          , (Flag Hugs,([] , ["hugs"]), "compile with Hugs")])
      
      We can need to use several kinds of OptDescr for the same option, as in the 
      optimization Option (really a extreme case):
      
            ,multiOption "optimization"
               configOptimization (\v flags -> flags { configOptimization = v })
               [optArg' "n" (Flag . flagToOptimisationLevel)
                ....
                ....
                        "Build with optimization (n is 0--2, default is 1)",
                noArg (Flag NoOptimisation) []

Separate the phases of sdist better so that they can be reused in
cabal-install. This part is similar to Andrea Vezzosi's patch.
Separate the snapshot code rather than mixing it all in with prepareTree.
Use a proper withTempDirectory which fixes one FIXME.
Better separate UI code from actions, move the notices to sdist.

Using readFile to read dist/setup-config keeps the Handle open when we try to delete the file, causing an error. 
So we instead read the file strictly and close the Handle early.

So now it really gives just the lib name and not its location as well.
It turned out that we more often want just the name since we're copying
the same named file from one directory to another.
Taking a PackageIdentifier means we do the conversion to string in one
place rather than all over the place.
It also means we're chaning the lib names for nhc98 to include the lib
version number. This should not make any real difference to nhc98.

  This patch adds two new command line options to configure,
  --extra-include-dirs and extra-lib-dirs.
  These have effect over all the buildables in a project.

  What is missing now is support for reading these from the .cabal/config file.
  That will be done as part of ticket #223.

It's a bit more readable that way.

Does not yet have a configure flag to turn this behaviour on and off.
That can wait until after the command line flag infrastructure changes.

Especially instead of abusing a PackageIdentifier for the purpose.

Rather than having it in Version and its parser elsewhere.
The Package module already imports the Version module which exports the
VersionRange type.

It was combining the executable's hs-source-dirs with the library's
hs-source-dirs when pre-processing executables. This was inconsistent
with the search path used for finding ordinary .hs files and with
sdist and lead to confusing behaviour. See ticket #161.
If an executable needs source files from the library then it must specify
the right hs-source-dirs, including '.' if appropriate.
The behaviour is that if hs-source-dirs is not specified then the default
is '.' however if hs-source-dirs is specified then '.' is not implicitly
added. If it's needed then it must be added explicitly. This was always
the case for ordinary .hs files, this patch just brings things into line
for files that need pre-processing.

It now gets line wrapped automatically by the logging functions

This GetOpt patch was sent the the libraries list by Eelis van der Weegen
with the explanation:
There is a bug in System.Console.GetOpt causing it to mistakenly reject
options as ambiguous. Example:
  optsDesc = [Option "" ["color", "colour"] (ReqArg id "color") ""]
Output:
  option `--col' is ambiguous; could be one of:
      --color=color, --colour=color  Foreground color
      --color=color, --colour=color  Foreground color
This error is silly, because the two alternatives listed are the same option.

(pkgName . packageId) and (pkgVersion . packageId)
turn out to be very common so give them names.

They have all been moved to tests/UnitTest/
So we don't need so much CPP in the ordinary modules now.

If we're bundling a whole copy of ReadP then why bother trying to use
the version from the base package, especially when that requires hacks
to use the H98 version with some compilers and the non-H98 version in
base. It just makes testing harder because we're using different versions
with different compilers.
As a bonus, hugs should no longer need the -98 flag to use Cabal.
Added all the type signatures back in and fixed some warnings.

Since we've dropped ghc-6.2 compatibility we can now use Data.Tree directly.

not defaultMainWithHooks defaultUserHooks since the latter is deprecated

Fixes ticket #257

Should eliminate confusion with doing: cabal configure --prefix=~/local
Instead use --prefix ~/local or --prefix=$HOME/local

Better type safety and more robust parsing.

Also add YHC compiler flavour.

We get more robust parsing and comparisons of arch names this way
and it'll allows us to detect and warn about unknown arches.

For Hugs, nhc98 and other compilers we do not know what packages are
already installed, so we just make some up, pretend that they do exist
and just hope for the best. We make them up based on what other package
the package we're currently building happens to depend on.
See inventBogusPackageId. Let's hope they really are installed... :-)
One could see this as all rather redundant - carefully making up bogus
information to satisfy a careful check. I prefer to see it as making
explicit something that was previously implicit. The proper solution is
to discover what packages are currently installed.

See http://hackage.haskell.org/trac/hackage/ticket/98#comment:17

Tested using Agda which uses several .hs-boot files.

Any users of custom wrapText versions can go from the underlying wrapLine

This should fix ticket #120 in future which is the problem where you do
something like "sudo runghc Setup install" and you accidentally end up
using a different version of the compiler or of the Cabal lib and you get
an unhelpful error message:
> Setup.hs: error reading ./.setup-config; run "setup configure" command?
Well now you'll get a helpful error message:
> setup: You need to re-run the 'configure' command. The version of Cabal
> being used has changed (was Cabal-1.3.6, now Cabal-1.3.7).
If the compiler version being used has changed too we get the extra helpful:
> setup: You need to re-run the 'configure' command. The version of Cabal
> being used has changed (was Cabal-1.3.6, now Cabal-1.3.7). Additionally
> the compiler is different (was ghc-6.8, now ghc-6.9) which is probably
> the cause of the problem.
Of course this does not help for older versions of Cabal but there's not a
lot we can do about that.

Rather than just using a string. This makes comparing OSs easier since
we can normalise them once when we parse rather than every time we compare.
Also makes it easy to discover when a package mentions an unknown OS since
it's marked as Other "whatever".

So we'll not have to keep adjusting newline breaks.

The real difficulty with changing the license stuff is the parser in current
and older cabal versions is very fragile, it parses using Read so only
recognises those exact enum values and if parsing fails, then parsing the
whole .cabal file fails. We really need to make this more permissive for all
the enumerations so that we can make changes in future.

No change to the defaults.