Package jenga v0.9.0


Jenga_lib__AliasAlias.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_lib__ApiJenga 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.
Jenga_lib__BuildThis 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.
Jenga_lib__BuilderLayer error monad within tenacious monad
Jenga_lib__Cat_apiCat_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.
Jenga_lib__CliCommand line interface entry point
Jenga_lib__Cmd_buildEntry point to run Jenga as directed by the command line
Jenga_lib__ConfigThe representation of the various command line options. Further configuration (not exposed to casual users) is in
Jenga_lib__DbDb 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.
Jenga_lib__DepDep.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.
Jenga_lib__EnvEnv.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.
Jenga_lib__File_accessA global throttle for the file system operations in jenga, to avoid exceeding the open file descriptor limits.
Jenga_lib__Finish_time_estimatorThis 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.
Jenga_lib__ForkerBecause 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.
Jenga_lib__FsModule supporting interface to file-system -- stat, digest, glob. Services: Digest caching & inotify wrapping (as hearts).
Jenga_lib__InterningHash consing of string, for space savings, both on disk and in memory.
Jenga_lib__Jenga_clientThis module is the normal way to write ocaml code that talks to the jenga server. See for what kind of information can be exchanged between client and server.
Jenga_lib__Jenga_optionsVarious 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".
Jenga_lib__Jenga_root_interfaceS is the interface that a jengaroot must provide to jenga. This interface is not used when the rules are statically linked in (see build.mli).
Jenga_lib__Job_summaryThis 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 though.
Jenga_lib__Load_rootThis module implements loading the jengaroot (whose type is defined in using ocaml_plugin.
Jenga_lib__Located_errorSee api.mli for documentation.
Jenga_lib__LockingThis module limits the concurrency in jenga.
Jenga_lib__MessageThis module implements the two forms of logging in jenga:
Jenga_lib__MetricsThis 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.
Jenga_lib__PathThe type and operations on filesystem paths.
Jenga_lib__PersistThe 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.
Jenga_lib__ProgressThis module keeps tracks of different things for progress reporting:
Jenga_lib__ReasonA type representing the various errors that can happen in jenga. Compared to simply using Error.t, we have control over the display.
Jenga_lib__ReflectThe main entry point to the reflection api, which is documented in api.mli.
Jenga_lib__ReportableThis module allows the jenga server to incrementally send updates about build errors in a typed way to clients (see the errors rpc).
Jenga_lib__Rpc_intfAll the rpcs exposed by the jenga server.
Jenga_lib__Rpc_serverThis module starts the rpc server (unless configured not to), and ties together the modules that implements the various rpcs.
Jenga_lib__RuleRule.t supports the description of build-rules in jenga. Two varieties:
Jenga_lib__RulesetRuleset.t represent a set of rules, with lookup.
Jenga_lib__RunThe main entry points of jenga.
Jenga_lib__SandboxThis 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.
Jenga_lib__SchemeScheme.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.
Jenga_lib__Server_lockThis 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.
Jenga_lib__Special_pathsThe 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 "".
Jenga_lib__SystemModule for OS specific configuration.
Jenga_lib__VarA table of registered environment variables, with typed access


Tenacious_lib__Dlistdifference lists: a representation for lists supporting constant-time append
Tenacious_lib__GraphA global graph of async computations used by tenacious: each node normally corresponds to a single execution of a memoize: if memoize's heart gets broken, we create a new node next time it's demanded.
Tenacious_lib__RingA Ring is a bag structure; similar to Core.Bag.
Tenacious_lib__Tenacious_intfTenacious.t -- A type for "Tenacious computations".


  • Jane Street Group, LLC <>
change log
  • Apache-2.0