The type for memoizers. Provides a context to issue memoizable operations.

Command line tools.

Memo environment lookups.

The type for tool lookups. Given a command line tool specification returns a file path to the tool executable or an error message mentioning the tool if it cannot be found.

env_tool_lookup ~sep ~var env is a tool lookup that gets the value of the var variable in env treats it as a sep separated search path and uses the result to lookup with B0_std.Os.Cmd.get with the memo's win_exe. var defaults to PATH and sep to B0_std.Fpath.search_path_sep.

The type for memoized tool invocations.

The type for memoized tools.

tool m t is tool t memoized. Use the resulting function to spawn the tool with the given arguments.

tool_opt m t is like tool, except None is returned if the tool cannot be found. y

spawn m ~reads ~writes ~env ~cwd ~stdin ~stdout ~stderr ~success_exits cmd spawns cmd once reads files are ready and makes files writes ready if the spawn succeeds and the file exists. The rest of the arguments are:

• stdin reads input from the given file. If unspecified reads from the standard input of the program running the build. Warning. The file is not automatically added to reads, this allows for example to use B0_std.Fpath.null.
• stdout and stderr, the redirections for the standard outputs of the command, see B0_zero.Op.Spawn.stdo. Path to files are created if needed. Warning. File redirections are not automatically added to writes; this allows for example to use B0_std.Fpath.null.
• success_exits the exit codes that determine if the build operation is successful (defaults to 0, use [] to always succeed)
• env, environment variables added to the build environment. This overrides environment variables read by the tool in the build environment except for forced one. It also allows to specify enovironment that may not be mentioned by the running tool's environment specification.
• cwd the current working directory. Default is the memo's cwd. In general it's better to avoid using relative file paths and tweaking the cwd. Construct make your paths absolute and invocations independent from the cwd.
• post_exec, if specified is called with the build operation after it has been executed or revived. If it was executed this is called before the operation gets recorded. It can be used to define the reads and writes of the operation if they are difficult to find out before hand. Do not access m in that function.
• k, if specified a function invoked once the spawn has succesfully executed with the operation and the exit code.
• stamp is used for caching if two spawns diff only in their stamp they will cache to different keys. This can be used to memoize tool whose outputs may not entirely depend on the environment, the cli stamp and the the content of read files.

Note. If the tool spawn acts on a sort of "main" file (e.g. a source file) it should be specified as the first element of reads, this is interpreted specially by certain build tracer.

spawn' is like spawn except the actual file paths written by the spawn need not be determined before the spawn. Only the root directory of writes need to be specified via writes_root. After the spawn executes the writes can be determined via the writes function, the returned paths must be absolute and be prefixed by writes_root (defaults to recursively list all the files rooted in writes_root).

run_proc m proc calls proc () and handles any failure. This also catches non-asynchronous uncaught exceptions and turns them into `Fail notification operations.

fail m fmt ... fails the procedure via a notify operation.

fail_if_error m r is v if r is Ok v and fail m "%s" e if r is Error _.

read_file m p declares path p to be ready, that is exists and is up-to-date in b. This is typically used with source files and files external to the build like installed libraries.

ready_files m ps is List.iter (ready_files m) ps.

read m file k is a future that determines with the contents s of file file when it becomes ready in m.

write m ~reads file w writes file with data w () and mode mode (defaults to 0o644) when reads are ready. w's result must only depend on reads, mode and stamp (defaults to "") and should not perform other side effects on the file system.

copy m ~mode ?linenum src ~dst copies file src to dst with mode mode (defaults to 0o644) when src is ready. If linenum is specified, the following line number directive is prependend in dst to the contents of src:

#line $(linenum) "$(src)"

copy_to_dir ~src_root src dir is copy src ~dst_dir with dst defined as B0_std.Fpath.reroot ~src_root ~dst_root:dst_dir src

Otherwise said, src gets copied in a subpath of dst defined by Fpath.strip_prefix src_root src. src_root defaults to Fpath.parent src which means that src gets copied at the root of dst.

ready_and_copy_to_dir is like copy_to_dir but calls ready_file on the copied file.

ready_and_copy_dir m ~recurse src ~dst lists files of src and applies ready_and_copy_to_dir with the corresponding arguments.

src_root defaults to src which is the B0_std.Fpath.parent of the copied files. So elements of src are rooted at dst by default.

mkdir m dir p is a future that determines with () when the directory path p has been created with mode mode (defaults to 0o755). The behaviour with respect to file permission of intermediate path segments matches B0_std.Os.Dir.create.

delete m p is a future that determines with () when path p is deleted (trashed in fact) and free to reuse.

wait_files m files is a future that deterines with () when all files are ready in m. FIXME Unclear whether we really want this, but somehow it's part of the primitives.

mark m is m's mark.

mark m mark is m but operations performed on m are marked by mark.

notify m kind msg is a notification msg of kind kind. Note that a `Fail notification will entail an an has_failures on the memo, see also fail and fail_if_error.

notify_if_error m kind ~use r is v if r is Ok v. If r is Error e, a notification of kind kind is added to m and use is returned. Note that a `Fail notification will entail an has_failures on the memo, see also fail and fail_if_error.

The type for memoizer feedback.

make is a simpler make_zero

• hash_fun defaults to B0_std.Hash.Xxh3_64.
• jobs defaults to B0_std.Os.Cpu.logical_count.
• env defaults to B0_std.Os.Env.current
• cwd defaults to B0_std.Os.Dir.cwd
• cache_dir is the cache directory.
• trash_dir is the trash directory.
• feedback defaults to a nop.
• forced_env_vars, defaults to [].

with_feedback m feedback is m with feedback replaced by feedback.

delete_trash ~block m is B0_zero.Trash.delete ~block (trash m).

hash_string m s is B0_zero.Reviver.hash_string (reviver m) s.

hash_file m f is B0_zero.Reviver.hash_file (reviver m) f. Note that these file hashes operations are memoized.

stir ~block m runs the memoizer a bit. If block is true blocks until the memoizer is stuck with no operation to execute.

status m looks for aggregate errors in m in ops m, see B0_zero.Op.aggregate_error for details.

Usually called after a blocking stir to check everything executed as expected. The function itself has no effect more operations can be on m afterwards. If you are only interested in checking if a failure occured in the memo has_failures is faster.

timestamp m gets a clock time stamp.

clock m is m's clock.

cpu_clock m is m's cpu clock.

env m is the environment of m. The environment read by the tools' declared environment variables.

exec m is m's executors.

forced_env_vars m are the forced environment variables of m. These variables are put in the stamped environment of any tool despite what it declares to access.

guard m is m's guard.

has_failures m is true iff at least one operation has failed.

ops m is the list of operations that were submitted to the memoizer

reviver m is m's reviver.

tool_lookup m is m's tool lookup function.

trash m is m's trash.

win_exe m is true if we spawn windows executables. This affects tool lookups. Defaults to Sys.win32.