jenga

Industrial strength, full-featured build system
Legend:
Library
Module
Module type
Parameter
Class
Class type
Library jenga
Module Jenga_lib . Api
module Path : sig ... end
module Located_error : sig ... end
module Kind : sig ... end
module Glob : sig ... end
module Alias : sig ... end

An Alias is the name of a symbolic target. Alias.create ~dir:"a" "foo" is what you get on the command line by writing jenga a/.foo. When no arguments are given at the command line, jenga interprets it as building the alias "DEFAULT" in the current directory.

module Sandbox : sig ... end

Sandboxing in the act of running a compilation into a separate directory, for the purpose of enforcing that dependencies and targets be properly specified (instead of trusting the user to get them right).

module Action : sig ... end
module Shell : sig ... end
module Var : sig ... end
module Dep : sig ... end

The jenga monad. It has two pieces to it:

Reflected and Reflect are the two parts of the reflection api of jenga, ie the api that allows the jenga rules to ask about the structure of the dependency graph. There have been two uses of this api so far:

  • generating the input to an other build system, for bootstrapping purpose. Given a target, you can ask what action builds it and what dependencies it has, and write a makefile rule that does that.
  • checking the sanity of dependencies. If you have systems that can only use vetted libraries, this can be used to get all the dependencies of such a system, and check that they are only vetted libraries.
module Reflected : sig ... end
module Reflect : sig ... end
module Rule : sig ... end

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.

module Scheme : sig ... end

A scheme describes, for a given directory, what rules are available in that directory. A scheme can include computation (in the form of Scheme.dep) but there are limits to what can be done, because jenga will reject anything that looks like a dependency cycle.

module Env : sig ... end

The jenga API intentionally shadows printf, so that if opened in jenga/root.ml the default behaviour is for printf to print via jenga's message system, and not directly to stdout. Sending to stdout makes no sense for a dameonized jenga server.

printf sends messages via jenga's own message system, (i.e. not directly to stdout). Messages are logged, transmitted to jenga trace clients, and displayed to stdout if the jenga server is not running as a daemon.

printf_verbose is like printf, except the message are tagged as `verbose', so allowing non-verbose clients to mask the message

There is no need to append a \n to the string passed to printf or printf_verbose.

val printf : ( 'a, unit, string, unit ) Core.format4 -> 'a
val printf_verbose : ( 'a, unit, string, unit ) Core.format4 -> 'a
val run_action_now : Action.t -> unit Async.Deferred.t
val run_action_now_stdout : Action.t -> string Async.Deferred.t