Distribution.Simple.SetupHooks.Rule

A rule consists of:

• an action to run to execute the rule,

• a description of the rule inputs and outputs.

Use staticRule or dynamicRule to construct a rule, overriding specific fields, rather than directly using the Rule constructor.

A unique identifier for a Rule.

A rule with static dependencies.

Prefer using this smart constructor instead of Rule whenever possible.

See also dynamicRule which adds support for dynamic dependencies.

A rule with dynamic dependencies, which consists of two parts:

• a dynamic dependency computation, that returns additional edges to be added to the build graph, together with an additional piece of data,

• the command to execute the rule itself, which receives the additional piece of data returned by the dependency computation.

Prefer using this smart constructor instead of Rule whenever possible.

Use staticRule if you do not have any dynamic dependencies.

Commands to execute a rule:

• for a rule with static dependencies, a single command,

• for a rule with dynamic dependencies, a command for computing dynamic dependencies, and a command for executing the rule.

Prefer using staticRule and dynamicRule instead of the (internal) constructors of RuleCommands.

A command consists of a statically-known action together with a (possibly dynamic) argument to that action.

For example, the action can consist of running an executable (such as happy or c2hs), while the argument consists of the variable component of the command, e.g. the specific file to run happy on.

Internal datatype used for commands, both for the Hooks API (Command) and for the build system.

Run a Command.

Construct a command.

Prefer using this smart constructor instead of Command whenever possible.

A wrapper used to pass evidence of a constraint as an explicit value.

Both the rule command and the (optional) dynamic dependency command.

Only the (optional) dynamic dependency command.

The rule command together with the result of the (optional) dynamic dependency computation.

A dynamic dependency command.

The result of a dynamic dependency computation.

Project out the (optional) dependency computation command, so that it can be serialised without serialising anything else.

Obtain the (optional) IO action that computes dynamic dependencies.

Project out the command for running the rule, passing in the result of the dependency computation if there was one.

Obtain the IO action that executes a rule.

A collection of Rules.

Use the rules smart constructor instead of directly using the Rules constructor.

• Rules are registered using registerRule,

• Monitored files or directories are declared using addRuleMonitors; a change in these will trigger the recomputation of all rules.

The env type parameter represents an extra argument, which usually consists of information known to Cabal such as LocalBuildInfo and ComponentLocalBuildInfo.

A dependency of a rule.

A reference to an output of another rule.

Construct a collection of rules with a given label.

A label for the rules can be constructed using the static keyword, using the StaticPointers extension. NB: separate calls to rules should have different labels.

Example usage:

myRules :: Rules env
myRules = rules (static ()) $ \ env -> do { .. } -- use the monadic API here

An empty collection of rules.

A (fully resolved) location of a dependency or result of a rule, consisting of a base directory and of a file path relative to that base directory path.

In practice, this will be something like Location dir (moduleNameSymbolicPath mod . "hs"), where:

• for a file dependency, dir is one of the Cabal search directories,

• for an output, dir is a directory such as autogenComponentModulesDir or componentBuildDir.

Get a (relative or absolute) un-interpreted path to a Location.

A description of a file (or set of files) to monitor for changes.

Where file paths are relative they are relative to a common directory (e.g. project root), not necessarily the process current directory.

Monad for constructing rules.

Monad transformer for defining rules. Usually wraps the IO monad, allowing IO actions to be performed using liftIO.

The environment within the monadic API.

Internal function: run the monadic Rules computations in order to obtain all the Rules with their RuleIds.