Cabal-1.10.2.0: A framework for packaging Haskell software

Portability | portable
Maintainer | cabal-devel@haskell.org

Distribution.Simple.InstallDirs

Description

This manages everything to do with where files get installed (though does not get involved with actually doing any installation). It provides an `InstallDirs` type which is a set of directories for where to install things. It also handles the fact that we use templates in these install dirs. For example most install dirs are relative to some `$prefix` and by changing the prefix all other dirs still end up changed appropriately. So it provides a `PathTemplate` type and functions for substituting for these templates.

Synopsis

- data InstallDirs dir = InstallDirs {
  - prefix :: dir
  - bindir :: dir
  - libdir :: dir
  - libsubdir :: dir
  - dynlibdir :: dir
  - libexecdir :: dir
  - progdir :: dir
  - includedir :: dir
  - datadir :: dir
  - datasubdir :: dir
  - docdir :: dir
  - mandir :: dir
  - htmldir :: dir
  - haddockdir :: dir
  }
- type InstallDirTemplates = InstallDirs PathTemplate
- defaultInstallDirs :: CompilerFlavor -> Bool -> Bool -> IO InstallDirTemplates
- combineInstallDirs :: (a -> b -> c) -> InstallDirs a -> InstallDirs b -> InstallDirs c
- absoluteInstallDirs :: PackageIdentifier -> CompilerId -> CopyDest -> InstallDirs PathTemplate -> InstallDirs FilePath
- data CopyDest
  - = NoCopyDest
  - | CopyTo FilePath
- prefixRelativeInstallDirs :: PackageIdentifier -> CompilerId -> InstallDirTemplates -> InstallDirs (Maybe FilePath)
- substituteInstallDirTemplates :: PathTemplateEnv -> InstallDirTemplates -> InstallDirTemplates
- data PathTemplate
- data PathTemplateVariable
  - = PrefixVar
  - | BindirVar
  - | LibdirVar
  - | LibsubdirVar
  - | DatadirVar
  - | DatasubdirVar
  - | DocdirVar
  - | HtmldirVar
  - | PkgNameVar
  - | PkgVerVar
  - | PkgIdVar
  - | CompilerVar
  - | OSVar
  - | ArchVar
  - | ExecutableNameVar
  - | TestSuiteNameVar
  - | TestSuiteResultVar
- toPathTemplate :: FilePath -> PathTemplate
- fromPathTemplate :: PathTemplate -> FilePath
- substPathTemplate :: PathTemplateEnv -> PathTemplate -> PathTemplate
- initialPathTemplateEnv :: PackageIdentifier -> CompilerId -> PathTemplateEnv
- platformTemplateEnv :: Platform -> PathTemplateEnv
- compilerTemplateEnv :: CompilerId -> PathTemplateEnv
- packageTemplateEnv :: PackageIdentifier -> PathTemplateEnv
- installDirsTemplateEnv :: InstallDirs PathTemplate -> PathTemplateEnv

# Documentation

data InstallDirs dir Source

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 |

Fields

prefix :: dir
bindir :: dir
libdir :: dir
libsubdir :: dir
dynlibdir :: dir
libexecdir :: dir
progdir :: dir
includedir :: dir
datadir :: dir
datasubdir :: dir
docdir :: dir
mandir :: dir
htmldir :: dir
haddockdir :: dir

Instances

Functor InstallDirs |
Read dir => Read (InstallDirs dir) |
Show dir => Show (InstallDirs dir) |
Monoid dir => Monoid (InstallDirs dir) |

type InstallDirTemplates = InstallDirs PathTemplate Source

The installation directories in terms of `PathTemplate`s 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 compatibility 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 multiple versions of packages and building the same package for multiple compilers we append the libsubdir to get: `/usr/lib64/$pkgid/$compiler`.

An additional complication is the need to support relocatable packages on systems which support such things, like Windows.

defaultInstallDirs :: CompilerFlavor -> Bool -> Bool -> IO InstallDirTemplates Source

combineInstallDirs :: (a -> b -> c) -> InstallDirs a -> InstallDirs b -> InstallDirs cSource

absoluteInstallDirs :: PackageIdentifier -> CompilerId -> CopyDest -> InstallDirs PathTemplate -> InstallDirs FilePath Source

Convert from abstract install directories to actual absolute ones by substituting for all the variables in the abstract paths, to get real absolute path.

data CopyDest Source

The location prefix for the copy command.

Constructors

NoCopyDest |
CopyTo FilePath |

Instances

Eq CopyDest |
Show CopyDest |

prefixRelativeInstallDirs :: PackageIdentifier -> CompilerId -> InstallDirTemplates -> InstallDirs (Maybe FilePath)Source

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

substituteInstallDirTemplates :: PathTemplateEnv -> InstallDirTemplates -> InstallDirTemplates Source

Substitute the install dir templates into each other.

To prevent cyclic substitutions, only some variables are allowed in particular dir templates. If out of scope vars are present, they are not substituted for. Checking for any remaining unsubstituted vars can be done as a subsequent operation.

The reason it is done this way is so that in `prefixRelativeInstallDirs` we can replace `prefix` with the `PrefixVar` and get resulting `PathTemplate`s that still have the `PrefixVar` in them. Doing this makes it each to check which paths are relative to the $prefix.

data PathTemplate Source

An abstract path, posibly containing variables that need to be substituted for to get a real `FilePath`.

Instances

Read PathTemplate |
Show PathTemplate |

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
HtmldirVar | The `$htmldir` 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`
OSVar | The operating system name, eg `windows` or `linux`
ArchVar | The cpu architecture name, eg `i386` or `x86_64`
ExecutableNameVar | The executable name; used in shell wrappers
TestSuiteNameVar | The name of the test suite being run
TestSuiteResultVar | The result of the test suite being run, eg `pass`, `fail`, or `error`.

Instances

Eq PathTemplateVariable |
Read PathTemplateVariable |
Show PathTemplateVariable |

toPathTemplate :: FilePath -> PathTemplate Source

Convert a `FilePath` to a `PathTemplate` including any template vars.

fromPathTemplate :: PathTemplate -> FilePath Source

Convert back to a path, any remaining vars are included

substPathTemplate :: PathTemplateEnv -> PathTemplate -> PathTemplate Source

initialPathTemplateEnv :: PackageIdentifier -> CompilerId -> PathTemplateEnvSource

The initial environment has all the static stuff but no paths

platformTemplateEnv :: Platform -> PathTemplateEnvSource

compilerTemplateEnv :: CompilerId -> PathTemplateEnvSource

packageTemplateEnv :: PackageIdentifier -> PathTemplateEnvSource

installDirsTemplateEnv :: InstallDirs PathTemplate -> PathTemplateEnvSource