13.5 Execution Architecture

An amake system may encompass multiple amake processes executing for multiple users on multiple computers.

If target caching is enabled, multiple tcd processes may be executing on multiple computers. They are started as needed, and exit when idle. In contrast, a single long-lived sqld must be executing.

The components of a executing amake system are shown in this picture:

Legend:

• A solid oval denotes a process.
• A rectangle denotes a file, or set of files of a particular type. Files are grouped into filesystems, which may or may not correspond to operating-system filesystems.
• Paired ovals or rectangles denote multiplicity.
• An solid arc between processes denotes a fork and an exec.
• A solid arc from a process to a file denotes reading and/or writing.
• A dotted arc between processes denotes reading and/or writing through a socket.
• A dotted oval denotes a shared library.
• A solid arc from a process to a shared library denotes calling an input/output function.
• A dotted arc between a shared library and a process denotes writing through a pipe.

In the picture, the multiple amake processes indicate that at least one user has started amake from a shell. Of course, an amake process can start other amake processes, via a rule's commands.

In deciding whether a target must be updated, amake reads the target's .cmd and .dep files, writing a new .cmd file as needed. These files are assumed to be in a normal user-private workspace.

If a target must be updated, amake starts an amake-collect process for the target and executes the its rule's commands. The commands call wrapper functions in the libaccess shared-library, which write the target's dependency data to its amake-collect process, via an anonymous pipe. amake-collect reads the target's dependency data from the pipe and writes the target's .dep and .sib files. As usual, the commands update the target file in the workspace filesystem.

If the target cache is enabled, the sqld and cache filesystem are assumed to be available. The cache filesystem can be shared among workspaces on a single host, or shared among hosts (via NFS, for example). Files are stored in the cache filesystem below directories whose names prevent collisions. The database filesystem holds metadata about those files (e.g., names and checksums).

If the target cache is enabled, amake consults the target-cache subsystem, prior to, and perhaps instead of, executing a rule's commands. If needed, a tcd process is started. Each amake process has a single tcd process, with which it communicates via a named socket. tcd searches the cache for a suitable target, by querying sqld and analyzing candidates in the cache filesystem. If successful, files are hard-linked or copied to the workspace filesystem. If unsuccessful, the rule's commands are executed as usual, the updated target's metadata is stored by sqld, and the updated target's files are hard-linked or copied to the cache filesystem. A target's siblings are stored in the cache filesystem as a single tar file.