package jenga

Alias.t is a symbolic target, ie build-goal which is not associated with any generated files. It is used as a way of asking jenga to do an arbitrary Dep computation, for instance build a set of files ("all the libraries in the tree" for instance) and run actions that produce no target, like tests. The user indicates an alias on the command line with a leading period. So for example ".DEFAULT" or ".runtest". Aliases are directory relative.

Jenga API - Monadic Style. This signature provides the interface between the `user-code' which describes the build rules etc for a specific instance of jenga, and the core jenga build system. What is ultimately the main entry point of this module is Env, at the bottom.

This module is the part of jenga that interprets the Dep monad, by running actions in topological order of dependency, rerunning as needed, creating the persistent state etc. This module is not meant to be used directly, except for the Jr_spec type.

Layer error monad within tenacious monad

Cat_api.string is the string displayed by "jenga cat-api". The .ml corresponding to this .mli is generated from the text of api.mli, by stripping CRs, but otherwise leaving comments.

Command line interface entry point

Entry point to run Jenga as directed by the command line

Db contains types which will be stored persistently, so jenga doesn't need to rerun all the actions on restart. This is different from make which does not need persistent state, because instead of storing the knowledge that dependencies+action produced targets, it uses timestamps dependencies > timestamps of targets to claim that targets need to be recreated, and it doesn't even make record the dependency on the action. Most types do not expose bin_ios because there is some sharing in the serialized format across values (see With_index), and so they cannot be serialized independently.

Dep.t is the central type of jenga's API, supporting both the description of dependencies and computing dependencies with arbitrary dependencies. See documentation for individual items in api.mli.

Env.t is the value that contains all the configuration related to build rules that a user of the jenga library can provide to jenga. See api.mli for documentation of the various fields.

A global throttle for the file system operations in jenga, to avoid exceeding the open file descriptor limits.

This module implements the guessing of when the build will finished based on how the amount of remaining work changes, which is shown in the output of jenga monitor and jenga --progress.

Because forking is so expensive (even if memory is copied lazily, the page table is copied eagerly, which makes it very costly when the forking process uses a lot of memory), this module is used to hold a number of processed forked off the main jenga process early on, when jenga uses little memory. Jenga can then ask these processes to cheaply spawn commands.

Module supporting interface to file-system -- stat, digest, glob. Services: Digest caching & inotify wrapping (as hearts).

Hash consing of string, for space savings, both on disk and in memory.

This module is the normal way to write ocaml code that talks to the jenga server. See rpc_intf.ml for what kind of information can be exchanged between client and server.

Various configuration options for jenga meant for development or debugging, not for casual users. These are specified as an sexp in the env var "JENGA_OPTIONS".

This module contains types that represents either running jobs, or finished jobs, for the purpose of displaying them to the user. None of this is saved persistently. The actual displaying is done in message.ml though.

This module implements loading the jengaroot (whose type is defined in jenga_root_interface.ml) using ocaml_plugin.

See api.mli for documentation.

This module limits the concurrency in jenga.

This module implements the two forms of logging in jenga:

This module is used to track performance. Counter are used to keep track of events such as "ran an action", and Memory keeps track of allocation rates, and global properties like the amount of live memory. jenga writes the collected information to .jenga/metrics everytime jenga is done building (and then quits, or waits for filesystem changes). ../benchmarking/bench.exe can be used to build and gather these metrics files, and compare various versions of jenga or the jenga rules against one another.

The type and operations on filesystem paths.

The module that handles the jenga database, loading it on starting and saving it periodically, assuming something needs to be saved. Manipulation of the database is done in other places.

This module keeps tracks of different things for progress reporting:

A type representing the various errors that can happen in jenga. Compared to simply using Error.t, we have control over the display.

The main entry point to the reflection api, which is documented in api.mli.

This module allows the jenga server to incrementally send updates about build errors in a typed way to clients (see the errors rpc).

This module starts the rpc server (unless configured not to), and ties together the modules that implements the various rpcs.

Rule.t supports the description of build-rules in jenga. Two varieties:

Ruleset.t represent a set of rules, with lookup.

The main entry points of jenga.

This sandbox is a way of running the action that attempts to detect rules that are incorrectly described. We run the action in such a way that relative paths in actions can only access specified dependencies (to find missing dependencies). Files that are specified to be targets but are not created, or created but not specified to be targets, will be found as well.

Scheme.t supports the description of rule-generation schemes in jenga, where the scheme may itself have dependencies. This allows generation of rules based on a glob pattern, say *.c, or generation w.r.t to a config file.

This module prevents running multiple jengas in the same directory, as that would not work. It also writes to disk where the jenga server is listening, which can be queried by anything that needs to find the server.

The names of various files that jenga itself knows about. Jenga created all its files below .jenga, but knows about a few other files, like the "jengaroot.ml".

Module for OS specific configuration.

A table of registered environment variables, with typed access