Rule (jenga.Jenga_lib.Api.Rule)

A rule specifies how to build a Goal.t. There is no nothing of scoping or permissions, so all rules can be referred to at the command line, and by any Dep.t.

include sig ... end

val sexp_of_t : t ‑> Sexplib.Sexp.t

val create : targets:Path.t list ‑> Action.t Dep.t ‑> t

create ~targets action_dep specifies that the given static list of targets can be built by the action in the dep, and that action depends on the implicit dependencies (see Dep). A given file can only be the target of a single rule. A rule can only declare targets in the directories of the scheme that declares it (required so schemes can be evaluated lazily). The action must not depend on the filesystem other than how the given dependencies, and must create all the specified targets. These properties are assumed, or checked when using Sandbox. The dep itself can do arbitrary computation like reading generated files, but these do not become dependencies of running the action, only dependencies of figuring out what the action is. If you need a dynamic set of targets, you have two choices:

use Scheme.dep before building this rule (which is not a panacea, as it means building any alias in that directory will run that dep, so that's only reasonable for cheap computations)
create a tar ball instead of many targets If some of these targets are symlink, then the rule must depend on the target of the symlink.

val alias : Alias.t ‑> unit Dep.t list ‑> t

alias a means that requesting the build of the alias a must executing all the corresponding. This is not like phony targets in make, as these computations are cached and only run as needed. Same as for rules, the directory of the alias must be the directory on the scheme that contains the alias. Unlike rules, multiple definitions can be given for an alias. Building the alias then builds all the definitions.