Legend:
Library
Module
Module type
Parameter
Class
Class type
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.
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.
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).
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.
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.
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.
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