HORIZON HASKELLDocslts/ghc-9.10.x248f8f02026-10-05Search names, modules, packages, or :: a typeCtrl K

GHC 9.10.3 · lts/ghc-9.10.x · 248f8f0 · 2026-10-05

Modulecabal-install-3.12.1.0Haskell2010

Distribution.Client.ProjectPlanning.Types

Types used while planning how to build everything in a project.

Primarily this is the ElaboratedInstallPlan.

  • 17 types
  • 28 values
datadata SolverInstallPlan
#
Instances4Generic, Binary, Structured, Rep

Elaborated install plan types

32 declarations
datadata ElaboratedConfiguredPackage
#

Constructors

Instances11Eq, Show, Generic, Binary, Structured, IsNode, …
valueelabInplaceDependencyBuildCacheFiles
  1. :: DistDirLayout
  2. -> ElaboratedSharedConfig
  3. -> ElaboratedInstallPlan
  4. -> ElaboratedConfiguredPackage
  5. -> [FilePath]
#

The cache files of all our inplace dependencies which, when updated, require us to rebuild. See #4202 for more details. Essentially, this is a list of filepaths that, if our dependencies get rebuilt, will themselves get updated.

Note: the hash of these cache files gets built into the build cache ourselves, which means that we end up tracking transitive dependencies!

Note: This tracks the "build" cache file, but not "registration" or "config" cache files. Why not? Arguably we should...

Note: This is a bit of a hack, because it is not really the hashes of the SOURCES of our (transitive) dependencies that we should use to decide whether or not to rebuild, but the output BUILD PRODUCTS. The strategy we use here will never work if we want to implement unchanging rebuilds.

datadata ElaboratedPackageOrComponent
#

Constructors

Instances6Eq, Show, Generic, Binary, Structured, Rep
datadata ElaboratedComponent
#

Some extra metadata associated with an ElaboratedConfiguredPackage which indicates that the "package" in question is actually a single component to be built. Arguably it would be clearer if there were an ADT which branched into package work items and component work items, but I've structured it this way to minimize change to the existing code (which I don't feel qualified to rewrite.)

Constructors

  • ElaboratedComponent
    • compSolverName :: Component

      The name of the component to be built according to the solver

    • compComponentName :: Maybe ComponentName

      The name of the component to be built. Nothing if it's a setup dep.

    • compLibDependencies :: [(ConfiguredId, Bool)]

      The *external* library dependencies of this component. We pass this to the configure script. The Bool indicates whether the dependency is a promised dependency (True) or not (False).

    • compLinkedLibDependencies :: [OpenUnitId]

      In a component prior to instantiation, this list specifies the OpenUnitIds which, after instantiation, are the actual dependencies of this package. Note that this does NOT include signature packages, which do not turn into real ordering dependencies when we instantiate. This is intended to be a purely temporary field, to carry some information to the instantiation phase. It's more precise than compLibDependencies, and also stores information about internal dependencies.

    • compExeDependencies :: [ConfiguredId]

      The executable dependencies of this component (including internal executables).

    • compPkgConfigDependencies :: [(PkgconfigName, Maybe PkgconfigVersion)]

      The pkg-config dependencies of the component

    • compExeDependencyPaths :: [(ConfiguredId, FilePath)]

      The paths all our executable dependencies will be installed to once they are installed.

    • compOrderLibDependencies :: [UnitId]

      The UnitIds of the libraries (identifying elaborated packages/ components) that must be built before this project. This is used purely for ordering purposes. It can contain both references to definite and indefinite packages; an indefinite UnitId indicates that we must typecheck that indefinite package before we can build this one.

Instances6Eq, Show, Generic, Binary, Structured, Rep
datadata ElaboratedPackage
#

Constructors

Instances6Eq, Show, Generic, Binary, Structured, Rep
datadata ElaboratedSharedConfig
#

Constructors

Instances5Show, Generic, Binary, Structured, Rep
datadata BuildStyle
#

This is used in the install plan to indicate how the package will be built.

Constructors

  • BuildAndInstall

    The classic approach where the package is built, then the files installed into some location and the result registered in a package db.

    If the package came from a tarball then it's built in a temp dir and the results discarded.

  • BuildInplaceOnly MemoryOrDisk

    For OnDisk: The package is built, but the files are not installed anywhere, rather the build dir is kept and the package is registered inplace.

    Such packages can still subsequently be installed.

    Typically BuildAndInstall packages will only depend on other BuildAndInstall style packages and not on BuildInplaceOnly ones.

    For InMemory: Built in-memory only using GHC multi-repl, they are not built or installed anywhere on disk. BuildInMemory packages can't be depended on by BuildAndInstall nor BuildInplaceOnly packages (because they don't exist on disk) but can depend on other BuildStyles.

    At the moment BuildInplaceOnly InMemory is only used by the repl command.

    We use single constructor BuildInplaceOnly as for most cases inplace packages are handled similarly.

Instances9Eq, Ord, Show, Generic, Semigroup, Monoid, …
datadata MemoryOrDisk
#

How BuildInplaceOnly component is built.

OnDiskInMemory
Instances7Eq, Ord, Show, Generic, Binary, Structured, …
datadata NotPerComponentReason
#

Why did we fall-back to a per-package build, instead of using a per-component build?

Constructors

Instances6Eq, Show, Generic, Binary, Structured, Rep
datadata NotPerComponentBuildType
#
CuzConfigureBuildTypeCuzCustomBuildTypeCuzMakeBuildType
Instances6Eq, Show, Generic, Binary, Structured, Rep

Build targets

11 declarations
datadata ComponentTarget
#

Specific targets within a package or component to act on e.g. to build, haddock or open a repl.

Constructors

Instances7Eq, Ord, Show, Generic, Binary, Structured, …
datadata SubComponentTarget
#

Either the component as a whole or detail about a file or module target within a component.

Constructors

Instances7Eq, Ord, Show, Generic, Binary, Structured, …

Setup script

1 declaration
datadata SetupScriptStyle
#

There are four major cases for Setup.hs handling:

  1. build-type Custom with a custom-setup section

  2. build-type Custom without a custom-setup section

  3. build-type not Custom with cabal-version > $our-cabal-version

  4. build-type not Custom with cabal-version <= $our-cabal-version

It's also worth noting that packages specifying cabal-version: >= 1.23 or later that have build-type Custom will always have a custom-setup section. Therefore in case 2, the specified cabal-version will always be less than 1.23.

In cases 1 and 2 we obviously have to build an external Setup.hs script, while in case 4 we can use the internal library API. In case 3 we also have to build an external Setup.hs script because the package needs a later Cabal lib version than we can support internally.

SetupCustomExplicitDepsSetupCustomImplicitDepsSetupNonCustomExternalLibSetupNonCustomInternalLib
Instances6Eq, Show, Generic, Binary, Structured, Rep