ghc-6.12.3: The GHC APISource codeContentsIndex
PackageConfig
Contents
PackageId
The PackageConfig type: information about a package
Description
Package configuration information: essentially the interface to Cabal, with some utilities
Synopsis
mkPackageId :: PackageIdentifier -> PackageId
packageConfigId :: PackageConfig -> PackageId
type PackageConfig = InstalledPackageInfo_ ModuleName
data InstalledPackageInfo_ m = InstalledPackageInfo {
installedPackageId :: InstalledPackageId
sourcePackageId :: PackageId
license :: License
copyright :: String
maintainer :: String
author :: String
stability :: String
homepage :: String
pkgUrl :: String
description :: String
category :: String
exposed :: Bool
exposedModules :: [m]
hiddenModules :: [m]
importDirs :: [FilePath]
libraryDirs :: [FilePath]
hsLibraries :: [String]
extraLibraries :: [String]
extraGHCiLibraries :: [String]
includeDirs :: [FilePath]
includes :: [String]
depends :: [InstalledPackageId]
hugsOptions :: [String]
ccOptions :: [String]
ldOptions :: [String]
frameworkDirs :: [FilePath]
frameworks :: [String]
haddockInterfaces :: [FilePath]
haddockHTMLs :: [FilePath]
}
display :: Text a => a -> String
data Version = Version {
versionBranch :: [Int]
versionTags :: [String]
}
data PackageIdentifier = PackageIdentifier {
pkgName :: PackageName
pkgVersion :: Version
}
defaultPackageConfig :: PackageConfig
packageConfigToInstalledPackageInfo :: PackageConfig -> InstalledPackageInfo
installedPackageInfoToPackageConfig :: InstalledPackageInfo_ String -> PackageConfig
Documentation

Mostly the compiler deals in terms of PackageNames, which don't have the version suffix. This is so that we don't need to know the version for the -package-name flag, or know the versions of wired-in packages like base & rts. Versions are confined to the package sub-system.

This means that in theory you could have multiple base packages installed (for example), and switch between them using -package/-hide-package.

A PackageId is a string of the form pkg>-<version.

PackageId
mkPackageId :: PackageIdentifier -> PackageIdSource
Turn a Cabal PackageIdentifier into a GHC PackageId
packageConfigId :: PackageConfig -> PackageIdSource
Get the GHC PackageId right out of a Cabalish PackageConfig
The PackageConfig type: information about a package
type PackageConfig = InstalledPackageInfo_ ModuleNameSource
data InstalledPackageInfo_ m Source
Constructors
InstalledPackageInfo
installedPackageId :: InstalledPackageId
sourcePackageId :: PackageId
license :: License
copyright :: String
maintainer :: String
author :: String
stability :: String
homepage :: String
pkgUrl :: String
description :: String
category :: String
exposed :: Bool
exposedModules :: [m]
hiddenModules :: [m]
importDirs :: [FilePath]
libraryDirs :: [FilePath]
hsLibraries :: [String]
extraLibraries :: [String]
extraGHCiLibraries :: [String]
includeDirs :: [FilePath]
includes :: [String]
depends :: [InstalledPackageId]
hugsOptions :: [String]
ccOptions :: [String]
ldOptions :: [String]
frameworkDirs :: [FilePath]
frameworks :: [String]
haddockInterfaces :: [FilePath]
haddockHTMLs :: [FilePath]
show/hide Instances
display :: Text a => a -> StringSource
data Version Source

A Version represents the version of a software entity.

An instance of Eq is provided, which implements exact equality modulo reordering of the tags in the versionTags field.

An instance of Ord is also provided, which gives lexicographic ordering on the versionBranch fields (i.e. 2.1 > 2.0, 1.2.3 > 1.2.2, etc.). This is expected to be sufficient for many uses, but note that you may need to use a more specific ordering for your versioning scheme. For example, some versioning schemes may include pre-releases which have tags "pre1", "pre2", and so on, and these would need to be taken into account when determining ordering. In some cases, date ordering may be more appropriate, so the application would have to look for date tags in the versionTags field and compare those. The bottom line is, don't always assume that compare and other Ord operations are the right thing for every Version.

Similarly, concrete representations of versions may differ. One possible concrete representation is provided (see showVersion and parseVersion), but depending on the application a different concrete representation may be more appropriate.

Constructors
Version
versionBranch :: [Int]

The numeric branch for this version. This reflects the fact that most software versions are tree-structured; there is a main trunk which is tagged with versions at various points (1,2,3...), and the first branch off the trunk after version 3 is 3.1, the second branch off the trunk after version 3 is 3.2, and so on. The tree can be branched arbitrarily, just by adding more digits.

We represent the branch as a list of Int, so version 3.2.1 becomes [3,2,1]. Lexicographic ordering (i.e. the default instance of Ord for [Int]) gives the natural ordering of branches.

versionTags :: [String]A version can be tagged with an arbitrary list of strings. The interpretation of the list of tags is entirely dependent on the entity that this version applies to.
show/hide Instances
data PackageIdentifier Source
The name and version of a package.
Constructors
PackageIdentifier
pkgName :: PackageNameThe name of this package, eg. foo
pkgVersion :: Versionthe version of this package, eg 1.2
show/hide Instances
defaultPackageConfig :: PackageConfigSource
packageConfigToInstalledPackageInfo :: PackageConfig -> InstalledPackageInfoSource
Turn a PackageConfig, which contains GHC ModuleNames into a Cabal specific InstalledPackageInfo which contains Cabal ModuleNames
installedPackageInfoToPackageConfig :: InstalledPackageInfo_ String -> PackageConfigSource
Turn an InstalledPackageInfo, which contains Cabal ModuleNames into a GHC specific PackageConfig which contains GHC ModuleNames
Produced by Haddock version 2.6.1