|Maintainer||Isaac Jones <email@example.com>|
|Definition of the LocalBuildInfo data type. This is basically
the information that is gathered by the end of the configuration
step which could include package information from ghc-pkg, flags
the user passed to configure, and the location of tools in the
The directories where we will install files for packages.
We have several different directories for different types of files since
many systems have conventions whereby different types of files in a package
are installed in different direcotries. This is particularly the case on
unix style systems.
|prefix :: dir|
|bindir :: dir|
|libdir :: dir|
|dynlibdir :: dir|
|libexecdir :: dir|
|progdir :: dir|
|includedir :: dir|
|datadir :: dir|
|docdir :: dir|
|htmldir :: dir|
|interfacedir :: dir|
|data InstallDirTemplates ||Source|
The installation dirctories in terms of PathTemplates that contain
The defaults for most of the directories are relative to each other, in
particular they are all relative to a single prefix. This makes it
convenient for the user to override the default installation directory
by only having to specify --prefix=... rather than overriding each
individually. This is done by allowing $-style variables in the dirs.
These are expanded by textual substituion (see substPathTemplate).
A few of these installation directories are split into two components, the
dir and subdir. The full installation path is formed by combining the two
together with /. The reason for this is compatability with other unix
build systems which also support --libdir and --datadir. We would like
users to be able to configure --libdir=/usr/lib64 for example but
because by default we want to support installing multiplve versions of
packages and building the same package for multiple compilers we append the
libdubdir to get: /usr/lib64/$pkgid/$compiler.
An additional complication is the need to support relocatable packages on
systems which support such things, like Windows.
|Convert from abstract install directories to actual absolute ones by
substituting for all the variables in the abstract paths, to get real
Check which of the paths are relative to the installation $prefix.
If any of the paths are not relative, ie they are absolute paths, then it
prevents us from making a relocatable package (also known as a "prefix
|An abstract path, posibly containing variables that need to be
substituted for to get a real FilePath.
|data PathTemplateVariable ||Source|
|PrefixVar||The $prefix path variable
|BinDirVar||The $bindir path variable
|LibDirVar||The $libdir path variable
|LibSubdirVar||The $libsubdir path variable
|DataDirVar||The $datadir path variable
|DataSubdirVar||The $datasubdir path variable
|DocDirVar||The $docdir path variable
|PkgNameVar||The $pkg package name path variable
|PkgVerVar||The $version package version path variable
|PkgIdVar||The $pkgid package Id path variable, eg foo-1.0
|CompilerVar||The compiler name and version, eg ghc-6.6.1
|Convert a FilePath to a PathTemplate including any template vars.
|Convert back to a path, ingoring any remaining vars
|The initial environment has all the static stuff but no paths
|Produced by Haddock version 2.1.0|