Compiler information used for resolving configurations. Some fields can be set to Nothing to indicate that the information is unknown.

Like classifyCompilerFlavor but compatible with the old ReadS parser.

It is compatible in the sense that it accepts only the same strings, eg GHC but not "ghc". However other strings get mapped to OtherCompiler. The point of this is that we do not allow extra valid values that would upset older Cabal versions that had a stricter parser however we cope with new values more gracefully so that we'll be able to introduce new value in future without breaking things so much.

The default compiler flavour to pick when compiling stuff. This defaults to the compiler used to build the Cabal lib.

However if it's not a recognised compiler then it's Nothing and the user will have to specify which compiler they want.

Make a CompilerInfo of which only the known information is its CompilerId, its AbiTag and that it does not claim to be compatible with other compiler id's.

Some compilers (notably GHC) support profiling and can instrument programs so the system can account costs to different functions. There are different levels of detail that can be used for this accounting. For compilers that do not support this notion or the particular detail levels, this is either ignored or just capped to some similar level they do support.

Some compilers support emitting debug info. Some have different levels. For compilers that do not the level is just capped to the level they do support.

Some compilers support optimising. Some have different levels. For compilers that do not the level is just capped to the level they do support.

We typically get packages from several databases, and stack them together. This type lets us be explicit about that stacking. For example typical stacks include:

[GlobalPackageDB]
[GlobalPackageDB, UserPackageDB]
[GlobalPackageDB, SpecificPackageDB "package.conf.inplace"]

Note that the GlobalPackageDB is invariably at the bottom since it contains the rts, base and other special compiler-specific packages.

We are not restricted to using just the above combinations. In particular we can use several custom package dbs and the user package db together.

When it comes to writing, the top most (last) package is used.

Some compilers have a notion of a database of available packages. For some there is just one global db of packages, other compilers support a per-user or an arbitrary db specified at some location in the file system. This can be used to build isloated environments of packages, for example to build a collection of related packages without installing them globally.

Is this compiler compatible with the compiler flavour we're interested in?

For example this checks if the compiler is actually GHC or is another compiler that claims to be compatible with some version of GHC, e.g. GHCJS.

if compilerCompatFlavor GHC compiler then ... else ...

Is this compiler compatible with the compiler flavour we're interested in, and if so what version does it claim to be compatible with.

For example this checks if the compiler is actually GHC-7.x or is another compiler that claims to be compatible with some GHC-7.x version.

case compilerCompatVersion GHC compiler of
  Just (Version (7:_)) -> ...
  _                    -> ...

Return the package that we should register into. This is the package db at the top of the stack.

Make package paths absolute

For the given compiler, return the extensions it does not support.

For the given compiler, return the flags for the supported extensions.

Does this compiler support parallel --make mode?

Does this compiler support reexported-modules?

Does this compiler support thinning/renaming on package flags?

Does this compiler have unified IPIDs (so no package keys)

Does this compiler support package keys?

Does this compiler support unit IDs?

Does this compiler support Backpack?

Does this compiler support a package database entry with: "dynamic-library-dirs"?

Does this compiler's "ar" command supports response file arguments (i.e. @file-style arguments).

Does this compiler support Haskell program coverage?

Does this compiler support profiling?

A simple implementation of main for a Cabal setup script. It reads the package description file using IO, and performs the action specified on the command line.

Like defaultMain, but accepts the package description as input rather than using IO to read it.

A version of defaultMain that is passed the command line arguments, rather than getting them from the environment.

Hooks allow authors to add specific functionality before and after a command is run, and also to specify additional preprocessors.

• WARNING: The hooks interface is under rather constant flux as we try to understand users needs. Setup files that depend on this interface may break in future releases.

A customizable version of defaultMain.

A customizable version of defaultMain that also takes the command line arguments.

A customizable version of defaultMainNoRead.

A customizable version of defaultMainNoRead that also takes the command line arguments.

Since: Cabal-2.2.0.0

Hooks that correspond to a plain instantiation of the "simple" build system

Basic autoconf UserHooks:

• postConf runs ./configure, if present.
• the pre-hooks preBuild, preClean, preCopy, preInst, preReg and preUnreg read additional build information from package.buildinfo, if present.

Thus configure can use local system information to generate package.buildinfo and possibly other files.

Empty UserHooks which do nothing.

Optional auxiliary package information file (pkgname.buildinfo)