| Copyright | Isaac Jones 2003-2004 |
|---|---|
| License | BSD3 |
| Maintainer | [email protected] |
| Portability | portable |
| Safe Haskell | None |
| Language | Haskell2010 |
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.
- data InstallDirs dir = InstallDirs {
- prefix :: dir
- bindir :: dir
- libdir :: dir
- libsubdir :: dir
- dynlibdir :: dir
- flibdir :: dir
- libexecdir :: dir
- libexecsubdir :: dir
- includedir :: dir
- datadir :: dir
- datasubdir :: dir
- docdir :: dir
- mandir :: dir
- htmldir :: dir
- haddockdir :: dir
- sysconfdir :: dir
- type InstallDirTemplates = InstallDirs PathTemplate
- defaultInstallDirs :: CompilerFlavor -> Bool -> Bool -> IO InstallDirTemplates
- defaultInstallDirs' :: Bool -> CompilerFlavor -> Bool -> Bool -> IO InstallDirTemplates
- combineInstallDirs :: (a -> b -> c) -> InstallDirs a -> InstallDirs b -> InstallDirs c
- absoluteInstallDirs :: PackageIdentifier -> UnitId -> CompilerInfo -> CopyDest -> Platform -> InstallDirs PathTemplate -> InstallDirs FilePath
- data CopyDest
- prefixRelativeInstallDirs :: PackageIdentifier -> UnitId -> CompilerInfo -> Platform -> InstallDirTemplates -> InstallDirs (Maybe FilePath)
- substituteInstallDirTemplates :: PathTemplateEnv -> InstallDirTemplates -> InstallDirTemplates
- data PathTemplate
- data PathTemplateVariable
- type PathTemplateEnv = [(PathTemplateVariable, PathTemplate)]
- toPathTemplate :: FilePath -> PathTemplate
- fromPathTemplate :: PathTemplate -> FilePath
- combinePathTemplate :: PathTemplate -> PathTemplate -> PathTemplate
- substPathTemplate :: PathTemplateEnv -> PathTemplate -> PathTemplate
- initialPathTemplateEnv :: PackageIdentifier -> UnitId -> CompilerInfo -> Platform -> PathTemplateEnv
- platformTemplateEnv :: Platform -> PathTemplateEnv
- compilerTemplateEnv :: CompilerInfo -> PathTemplateEnv
- packageTemplateEnv :: PackageIdentifier -> UnitId -> PathTemplateEnv
- abiTemplateEnv :: CompilerInfo -> Platform -> 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 directories. This is particularly the case on Unix style systems.
Constructors
| InstallDirs | |
Fields
| |
Instances
| Functor InstallDirs # | |
| Eq dir => Eq (InstallDirs dir) # | |
| Read dir => Read (InstallDirs dir) # | |
| Show dir => Show (InstallDirs dir) # | |
| Generic (InstallDirs dir) # | |
| Semigroup dir => Semigroup (InstallDirs dir) # | |
| (Semigroup dir, Monoid dir) => Monoid (InstallDirs dir) # | |
| Binary dir => Binary (InstallDirs dir) # | |
| type Rep (InstallDirs dir) # | |
type InstallDirTemplates = InstallDirs PathTemplate Source #
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/$libname/$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 #
defaultInstallDirs' :: Bool -> CompilerFlavor -> Bool -> Bool -> IO InstallDirTemplates Source #
combineInstallDirs :: (a -> b -> c) -> InstallDirs a -> InstallDirs b -> InstallDirs c Source #
absoluteInstallDirs :: PackageIdentifier -> UnitId -> CompilerInfo -> CopyDest -> Platform -> 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.
The location prefix for the copy command.
Constructors
| NoCopyDest | |
| CopyTo FilePath |
prefixRelativeInstallDirs :: PackageIdentifier -> UnitId -> CompilerInfo -> Platform -> 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
PathTemplates 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, possibly containing variables that need to be
substituted for to get a real FilePath.
Instances
data PathTemplateVariable Source #
Constructors
| PrefixVar | The |
| BindirVar | The |
| LibdirVar | The |
| LibsubdirVar | The |
| DynlibdirVar | The |
| DatadirVar | The |
| DatasubdirVar | The |
| DocdirVar | The |
| HtmldirVar | The |
| PkgNameVar | The |
| PkgVerVar | The |
| PkgIdVar | The |
| LibNameVar | The |
| CompilerVar | The compiler name and version, eg |
| OSVar | The operating system name, eg |
| ArchVar | The CPU architecture name, eg |
| 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
|
| BenchmarkNameVar | The name of the benchmark being run |
type PathTemplateEnv = [(PathTemplateVariable, PathTemplate)] Source #
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
initialPathTemplateEnv :: PackageIdentifier -> UnitId -> CompilerInfo -> Platform -> PathTemplateEnv Source #
The initial environment has all the static stuff but no paths
abiTemplateEnv :: CompilerInfo -> Platform -> PathTemplateEnv Source #