HORIZON HASKELLDocslts/ghc-9.10.xc74966e2026-09-27Search names, modules, packages, or :: a typeCtrl K

GHC 9.10.3 · lts/ghc-9.10.x · c74966e · 2026-09-27

Modulecabal-install-3.12.1.0Haskell2010

Distribution.Client.ProjectBuilding.Types

Types for the Distribution.Client.ProjectBuilding

Moved out to avoid module cycles.

  • 10 types
  • 2 values

Pre-build status

7 declarations
datadata BuildStatus
#

The build status for an individual package is the state that the package is in prior to initiating a (re)build.

This should not be confused with a BuildResult which is the result after successfully building a package.

It serves two purposes:

  • For dry-run output, it lets us explain to the user if and why a package is going to be (re)built.

  • It tell us what step to start or resume building from, and carries enough information for us to be able to do so.

Constructors

  • BuildStatusPreExisting

    The package is in the InstallPlan.PreExisting state, so does not need building.

  • BuildStatusInstalled

    The package is in the InstallPlan.Installed state, so does not need building.

  • BuildStatusDownload

    The package has not been downloaded yet, so it will have to be downloaded, unpacked and built.

  • BuildStatusUnpack FilePath

    The package has not been unpacked yet, so it will have to be unpacked and built.

  • BuildStatusRebuild FilePath BuildStatusRebuild

    The package exists in a local dir already, and just needs building or rebuilding. So this can only happen for BuildInplaceOnly style packages.

  • BuildStatusUpToDate BuildResult

    The package exists in a local dir already, and is fully up to date. So this package can be put into the InstallPlan.Installed state and it does not need to be built.

datadata BuildStatusRebuild
#

For a package that is going to be built or rebuilt, the state it's in now.

So again, this tells us why a package needs to be rebuilt and what build phases need to be run. The MonitorChangedReason gives us details like which file changed, which is mainly for high verbosity debug output.

Constructors

  • BuildStatusConfigure (MonitorChangedReason ())

    The package configuration changed, so the configure and build phases needs to be (re)run.

  • BuildStatusBuild (Maybe (Maybe InstalledPackageInfo)) BuildReason

    The configuration has not changed but the build phase needs to be rerun. We record the reason the (re)build is needed.

    The optional registration info here tells us if we've registered the package already, or if we still need to do that after building. Just Nothing indicates that we know that no registration is necessary (e.g., executable.)

datadata BuildReason
#

Constructors

  • BuildReasonDepsRebuilt

    The dependencies of this package have been (re)built so the build phase needs to be rerun.

  • BuildReasonFilesChanged (MonitorChangedReason ())

    Changes in files within the package (or first run or corrupt cache)

  • BuildReasonExtraTargets (Set ComponentName)

    An important special case is that no files have changed but the set of components the user asked to build has changed. We track the set of components we have built, which of course only grows (until some other change resets it).

    The Set ComponentName is the set of components we have built previously. When we update the monitor we take the union of the ones we have built previously with the ones the user has asked for this time and save those. See updatePackageBuildFileMonitor.

  • BuildReasonEphemeralTargets

    Although we're not going to build any additional targets as a whole, we're going to build some part of a component or run a repl or any other action that does not result in additional persistent artifacts.

datadata MonitorChangedReason a
#

What kind of change checkFileMonitorChanged detected.

Constructors

  • MonitoredFileChanged FilePath

    One of the files changed (existence, file type, mtime or file content, depending on the MonitorFilePath in question)

  • MonitoredValueChanged a

    The pure input value changed.

    The previous cached key value is also returned. This is sometimes useful when using a fileMonitorKeyValid function that is not simply (==), when invalidation can be partial. In such cases it can make sense to updateFileMonitor with a key value that's a combination of the new and old (e.g. set union).

  • MonitorFirstRun

    There was no saved monitor state, cached value etc. Ie the file for the FileMonitor does not exist.

  • MonitorCorruptCache

    There was existing state, but we could not read it. This typically happens when the code has changed compared to an existing FileMonitor cache file and type of the input value or cached value has changed such that we cannot decode the values. This is completely benign as we can treat is just as if there were no cache file and re-run.

Instances3Functor, Eq, Show

Build outcomes

5 declarations