BuildEnv.BuildOne

setupPackage prepares a package for building, returning instructions that compile its Setup script.

buildUnit computes build instructions to configure, build and install the unit using its Setup script. If the unit is a library, the instructions will also register it into a local package database using ghc-pkg.

Building packages

setupPackage

Arguments

:: Verbosity

-> Compiler

-> BuildPaths ForBuild

Overall build directory structure.

-> PkgDbDirs ForBuild

Package database directories (see getPkgDbDirsForBuild).

-> PkgDir ForPrep

Package directory (to find the Setup.hs).

-> PkgDir ForBuild

Package directory (to build the Setup.hs).

-> Map UnitId PlanUnit

All dependencies in the build plan.

-> ConfiguredUnit

The unit to build.

-> IO BuildScript

Setup a single package.

Returns a build script which compiles the Setup script.

buildUnit

Arguments

:: Verbosity

-> Compiler

-> BuildPaths ForBuild

Overall build directory structure.

-> PkgDbDirs ForBuild

Package database directories (see getPkgDbDirsForBuild).

-> PkgDir ForBuild

This package's directory (see getPkgDir).

-> UnitArgs

Extra arguments for this unit.

-> Map UnitId PlanUnit

All dependencies in the build plan.

-> ConfiguredUnit

The unit to build.

-> BuildScript

Return build steps to to configure, build and and installing the unit, including registering it in the package database if it is a library.

You can run the build script with executeBuildScript, or you can turn it into a shell script with script.

Note: executing the build script will fail if the unit has already been registered in the package database.

Package directory structure helpers

Note [Using two package databases]

We need two distinct package databases: we might want to perform the build in a temporary location, before everything gets placed into its final destination. The final package database might use a specific, baked-in installation prefix (in the sense of Setup configure --prefix pfx). As a result, this package database won't be immediately usable, as we won't have copied over the build products yet.

In order to be able to build packages in a temporary directory, we create a temporary package database that is used for the build, making use of it with Setup register --inplace. We also register the packages into the final package database using ghc-pkg --force: otherwise, ghc-pkg would error because the relevant files haven't been copied over yet.

data PkgDir use

The package name-version string and its directory.

Constructors

PkgDir

Fields

• pkgNameVer :: !String

  Package name-version string.

• pkgDir :: !FilePath

  Package directory.

getPkgDir

Arguments

:: FilePath

Working directory (used only to relativise paths to local packages).

-> Paths use

Overall directory structure to base the computation off.

-> ConfiguredUnit

Any unit from the package in question.

-> PkgDir use

Compute the package directory location.

data family PkgDbDirs use

The package database directories.

See Note [Using two package databases].

Instances

data PkgDbDirs 'ForBuild

Defined in BuildEnv.BuildOne

data PkgDbDirs 'ForBuild = PkgDbDirsForBuild {

• tempPkgDbDir :: !FilePath
• tempPkgDbSem :: !QSem
• finalPkgDbDir :: !FilePath
• finalPkgDbSem :: !QSem

}

data PkgDbDirs 'ForPrep

Defined in BuildEnv.BuildOne

data PkgDbDirs 'ForPrep = PkgDbDirsForPrep {

• tempPkgDbDir :: !FilePath

}

getPkgDbDirsForPrep :: Paths ForPrep -> PkgDbDirs ForPrep

Compute the paths of the package database directories we are going to use.

See Note [Using two package databases].

getPkgDbDirsForBuild :: Paths ForBuild -> IO (PkgDbDirs ForBuild)

Compute the paths of the package database directories we are going to use, and create some semaphores to control access to them in order to avoid contention.

See Note [Using two package databases].