GitLab

Cabal will look for data files to install relative to the directory given
in the data-dir field, allowing package authors to better structure their
source tree. There's no behavioural change by default.

Same as for the datadir. Eg for package Foo, you'd use
Foo_bindir=... Foo_datadir=... Foo_libexecdir=... ./Foo
The next step would be generating a wrapper script that allows
running the program inplace. It should also work for a library.

It was made redundant after the isSymbol test was removed.
Spotted by Igloo.

It's actually more appropriate anyway.
This means we don't need any Distribution.Compat.Exception.

Which do not grok OPTIONS_GHC or LANGUAGE pragmas

Partly as it is more likely not to clash with other users and since
in general different libs within a program may need different paths.

Added an environment variable, DATA_DIR, that is checked before the
installation data directory is used.

This is an alternative fix to creating a Distribution.Compat.Char

Otherwise we cannot compile with just ghc --make
which is actually essential for bootstrapping.

This is made worse by Show on Map being strange in GHC 6.4.
The code could be better, but it works, and all the ugliness is in
#if's that we can remove at some point down the line.

Also adjust the verbosity level we get during configure at -v3
Should make it a bit easier to track down failing calls.

If we see a birdtrack while we are in latex mode, then we stay in latex
mode - don't change into bird mode!

eg "Using Cabal-1.5.1 compiled by ghc-6.8"
Annoyingly ghc doesn't give us its full version number.

It's similar to dependencyClosure but looks at reverse dependencies.
For example it's useful to find all packages that depend on broken
packages and are thus themselves broken.

Keep the completed set as another PackageIndex rather than a list.
We want to return an index at the end anyway and in the mean time
we want to do lots of lookups to see if we've visited previously.

Useful for some more tricky queries.

We occasionally need to remove packages from an index
eg to restrict the choices of a dependency resolver.

This was the check for ghc-pkg failing. We cannot check for the
exception being an ExitException since that assumes ghc's
representation of the Exception type, whereas nhc98 defines:
type Exception = IOError

Otherwise it can (and does) really confuse people.
The problem is that the command $ ghc-pkg-6.9 describe '*' --user
returns a non-zero exit code if the user package db is empty.
ghc-pkg intends this exit code to tell us if the query returned
any results (one can use more complex queries as tests) but Cabal
interprets it as failure. Indeed we cannot distinguish it from
any other kind of failure from ghc-pkg.

Finds any cycles (strongly connected components) in the dependencies
of set of packages. This is useful for checking the correctness of
installation plans.

The one case where we need the pseudo top package we can use
PackageIndex.insert instead to get the same effect and there
are other cases in cabal-install where we do not want a pseudo
top package.

To take the index last like the other functions and like Data.Map.
It is actually more convenient that way round.

Just a bit of confusion over the behaviour of the --executable flag.

Passing --internal to the haddock stage does these things:
 * Does not pass --hide parameter to haddock
 * Passes --ignore-all-exports parameter
 * Appends "(internal documentation)" to the title