|
| Distribution.Simple.InstallDirs | | Portability | portable | | Stability | alpha | | Maintainer | Isaac Jones <ijones@syntaxpolice.org> |
|
|
|
| Description |
| 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
PATH.
|
|
| Synopsis |
|
|
|
| Documentation |
|
|
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.
| | Constructors | | InstallDirs | | | prefix :: dir | | | bindir :: dir | | | libdir :: dir | | | dynlibdir :: dir | | | libexecdir :: dir | | | progdir :: dir | | | includedir :: dir | | | datadir :: dir | | | docdir :: dir | | | htmldir :: dir | | | interfacedir :: dir | |
|
|  Instances | |
|
|
|
|
|
|
| data InstallDirTemplates | Source |
|
The installation dirctories in terms of PathTemplates that contain
variables.
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.
| | Constructors | | | Instances | |
|
|
|
|
|
| Convert from abstract install directories to actual absolute ones by
substituting for all the variables in the abstract paths, to get real
absolute path.
|
|
|
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
independent" package).
|
|
|
| An abstract path, posibly containing variables that need to be
substituted for to get a real FilePath.
| | Instances | |
|
|
| data PathTemplateVariable | Source |
|
| Constructors | | 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
|
| | Instances | |
|
|
|
| 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 0.9 |
