GitLab

An annoyance of the current Simple build system is that each phase
(build, install, etc) can be passed additional HookedBuildInfo which
gets merged into the PackageDescription. This means that we cannot
process the PackageDescription up front at configure time and just
store and reuse it later, we have to work from it each time afresh.

The recent addition of Components (libs, exes, test suites) and a
topoligical sort of the components in the LocalBuildInfo fell foul
of this annoyance. The LocalBuildInfo stored the entire component
which meant they were not updated with the HookedBuildInfo. This
broke packages with custom Setup.hs scripts that took advantage of
the HookedBuildInfo feature, including those with configure scripts.

The solution is to store not the list of whole components but the
list of component names. Then withComponentsLBI retrieves the actual
components from the PackageDescription which thus includes the
HookedBuildInfo.

Also moved the Components into an internal module because (for the
moment at least) it is part of the Simple build system, not part of
the package description.

At the top level we now have cabal/ and cabal-install/

This patch adds intrapackage dependency resolution so that components
(libraries, exes, test suites) are build in the correct order.  This mean it's
now possible to have, e.g., executables that depend on other executables defined
in the same package description: the build-tools namespace has been extended
accordingly.
  
Related to this change is the refactoring of the do-it-all preprocessSources
function, formerly invoked by initialBuildSteps, into a a function
preprocessComponent that is invoked when a component is being built.  This lets
us use executables defined in a package to be used as a custom preprocessor when
building other components.
  
Finally, a number of functions now operate on values of the sum type
PackageDescription.Component rather than specifically operating on Library or
Executable and so forth.

This makes it easier to build both html documentation and a hoogle
database:

  ./setup haddock [--html]   # build only HTML docs (default)
  ./setup haddock --hoogle   # build only Hoogle DB
  ./setup haddock --hoogle --html   # build both

The knownExtensions list had already got out of sync with the datatype.
Now we use an Enum instance to get the list of constructors.
Also, having the actual extensions in a separate type than UnknownExtension
and EnableExtension makes it easier to add extension disabling support
later.

New fields default-language and other-languages for specifying the
base languages for the package, e.g. Haskell98, Haskell2010
New fields default-extensions and other-extensions for the language
extensions. Separate from the old extensions field.
The separation lets us express the difference between declaring to
the outside world that a package uses certain languages or extensions
and whether certain languages or extensions should be applied to
all modules in the package component.

Probably needed in the case of foreign exports and TH.

When using "haddock --optghc-XTemplateHaskell" haddock will write out .o
and .hi files. This is bad because it replaces the ones we previously
built. This results in broken packages later on. Of course haddock
should not do this, it should write temp files elsewhere. The workaround
is to tell haddock to write the files to a temp dir.

In the LocalBuildInfo, for each component, for the list of component
dependencies, keep both the InstalledPackageId and the PackageId.
That way we don't need to keep converting the InstalledPackageId
to the PackageId, via the package index (which is just horrible).

It's a unified index again, rather than one for looking up by an
InstalledPackageId and one for the source PackageId. The new one
lets you look up by either. It also maintains the order of
preference of different installed packages that share the same
source PackageId. In configure we just pick the first preference.

Follow changes in Distribution.Simple.LocalBuildInfo (installedPkgs is
now an InstalledPackageIndex).

The --verbose flag is now called --verbosity

Now requireProgram doesn't take a version range and does not check
the program version (indeed it doesn't need to have one). The new
function requireProgramVersion takes a required program version
range and returns the program version. Also update callers.
Also fixes the check that GHC has a version number.

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.

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.

In addition to (hopefully) making clear what's going on
we now do the additional preprocessing for all the versions of haddock 
(but not for hscolour) and we run cpp before moving the files.

Otherwise we don't get links to types from packages that we don't
directly depend on.

That's already done by the Program framework so we were passing
those extra args in twice.

Have just a single module that provides both the case sensitive and
insensitive operations. Turns out we hardly use the case insensitive
operations, and the places where we do are not performance sensitive
at all. So we use the PackageSet implementation which stores the
packages case sensitively and tack on the case insensitive operations
but with linear time implementations rather than log time. For the
merged module/type name use PackageIndex because that is what older
released versions exported, so less needless client breakage.

The maximum verbosity value is deafening so >= the correct test.
This primarily affected haddock.

Turns out the feature to do case-insensitive lookups was only
needed in cabal-install (and only in one little part) and
elsewhere it causes problems. So use PackageSet instead.

Use cabal-devel@haskell.org as the maintainer in most cases except for
a few which were pre-existing modules copied from elsewhere or modules
like L.H.Extension which really belong to libraries@haskell.org
Remove the useless stability module. We have more detailed information
on stability elsewhere (in the version number and user guide).
Add more top level module documentation, taken from the source guide.

Now look in the right place to find the pre-processed source
files belongign to executables. Fixes ticket #252.

Fixes ticket #249

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