Cabal-1.22.2.0: A framework for packaging Haskell software

CopyrightIsaac Jones 2003-2004
LicenseBSD3
Maintainercabal-devel@haskell.org
Portabilityportable
Safe HaskellSafe-Inferred
LanguageHaskell98

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

Documentation

data InstallDirs dir

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 directories. This is particularly the case on Unix style systems.

Constructors

InstallDirs 

Fields

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

Instances

Functor InstallDirs 
Read dir => Read (InstallDirs dir) 
Show dir => Show (InstallDirs dir) 
Generic (InstallDirs dir) 
Monoid dir => Monoid (InstallDirs dir) 
Binary dir => Binary (InstallDirs dir) 
type Rep (InstallDirs dir) 

type InstallDirTemplates = InstallDirs PathTemplate

The installation directories 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 substitution (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/$pkgkey/$compiler.

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

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

absoluteInstallDirs :: PackageIdentifier -> PackageKey -> CompilerInfo -> CopyDest -> Platform -> InstallDirs PathTemplate -> InstallDirs FilePath

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

The location prefix for the copy command.

Constructors

NoCopyDest 
CopyTo FilePath 

Instances

prefixRelativeInstallDirs :: PackageIdentifier -> PackageKey -> CompilerInfo -> Platform -> InstallDirTemplates -> InstallDirs (Maybe FilePath)

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

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 PathTemplates that still have the PrefixVar in them. Doing this makes it each to check which paths are relative to the $prefix.

data PathTemplate

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

data PathTemplateVariable

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

PkgKeyVar

The $pkgkey package key path variable

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

AbiVar

The Compiler's ABI identifier, $arch-$os-$compiler-$abitag

AbiTagVar

The optional ABI tag for the compiler

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.

BenchmarkNameVar

The name of the benchmark being run

toPathTemplate :: FilePath -> PathTemplate

Convert a FilePath to a PathTemplate including any template vars.

fromPathTemplate :: PathTemplate -> FilePath

Convert back to a path, any remaining vars are included

initialPathTemplateEnv :: PackageIdentifier -> PackageKey -> CompilerInfo -> Platform -> PathTemplateEnv

The initial environment has all the static stuff but no paths