Documentation

A simple implementation of main for a Cabal setup script. This is the same as defaultMain, with added support for building libraries utilising runQ*.

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.

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

Since: 2.2.0.0

A customizable version of defaultMainNoRead.

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

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

A customizable version of defaultMain.

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

Empty UserHooks which do nothing.

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.

Does this compiler support profiling?

Does this compiler support Haskell program coverage?

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

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

Does this compiler support Backpack?

Does this compiler support unit IDs?

Does this compiler support package keys?

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

Does this compiler support thinning/renaming on package flags?

Does this compiler support reexported-modules?

Does this compiler support parallel --make mode?

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

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

Make package paths absolute

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

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:_)) -> ...
  _                    -> ...

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 ...

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.

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 support optimising. Some have different levels. For compilers that do not the level is just capped to the 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 (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.

Optional auxiliary package information file (pkgname.buildinfo)

Compatibility wrapper for Cabal pre-1.24.

Class of things that have a PackageIdentifier

Types in this class are all notions of a package. This allows us to have different types for the different phases that packages go though, from simple name/id, package description, configured or installed packages.

Not all kinds of packages can be uniquely identified by a PackageIdentifier. In particular, installed packages cannot, there may be many installed instances of the same source package.

Packages that have an installed unit ID

Class of installed packages.

The primary data type which is an instance of this package is InstalledPackageInfo, but when we are doing install plans in Cabal install we may have other, installed package-like things which contain more metadata. Installed packages have exact dependencies installedDepends.

Simplify the VersionRange expression in a Dependency. See simplifyVersionRange.

Describes a dependency on a source package (API)

A module identity uniquely identifies a Haskell module by qualifying a ModuleName with the UnitId which defined it. This type distinguishes between two packages which provide a module with the same name, or a module from the same package compiled with different dependencies. There are a few cases where Cabal needs to know about module identities, e.g., when writing out reexported modules in the InstalledPackageInfo.

Unsafely create a DefUnitId from a UnitId. Your responsibility is to ensure that the DefUnitId invariant holds.

Returns library name prefixed with HS, suitable for filenames

Make an old-style UnitId from a package identifier. Assumed to be for the public library

Create a unit identity with no associated hash directly from a ComponentId.

If you need backwards compatibility, consider using display instead, which is supported by all versions of Cabal.

A unit identifier identifies a (possibly instantiated) package/component that can be installed the installed package database. There are several types of components that can be installed:

• A traditional library with no holes, so that unitIdHash is Nothing. In the absence of Backpack, UnitId is the same as a ComponentId.
• An indefinite, Backpack library with holes. In this case, unitIdHash is still Nothing, but in the install, there are only interfaces, no compiled objects.
• An instantiated Backpack library with all the holes filled in. unitIdHash is a Just a hash of the instantiating mapping.

A unit is a component plus the additional information on how the holes are filled in. Thus there is a one to many relationship: for a particular component there are many different ways of filling in the holes, and each different combination is a unit (and has a separate UnitId).

UnitId is distinct from OpenUnitId, in that it is always installed, whereas OpenUnitId are intermediate unit identities that arise during mixin linking, and don't necessarily correspond to any actually installed unit. Since the mapping is not actually recorded in a UnitId, you can't actually substitute over them (but you can substitute over OpenUnitId). See also Distribution.Backpack.FullUnitId for a mechanism for expanding an instantiated UnitId to retrieve its mapping.

Backwards compatibility note: if you need to get the string representation of a UnitId to pass, e.g., as a -package-id flag, use the display function, which will work on all versions of Cabal.

A UnitId for a definite package. The DefUnitId invariant says that a UnitId identified this way is definite; i.e., it has no unfilled holes.

Type alias so we can use the shorter name PackageId.

The name and version of a package.

Construct a PackageName from a String

mkPackageName is the inverse to unPackageName

Note: No validations are performed to ensure that the resulting PackageName is valid

Since: 2.0.0.2

Convert PackageName to String

A package name.

Use mkPackageName and unPackageName to convert from/to a String.

This type is opaque since Cabal-2.0

Since: 2.0.0.2

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.

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.

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.