13.8 Target-Cache Subsystem

The target-cache subsystem provides another kind of build avoidance. If a target must be updated, and some user, on this host or some other host, has previously built a similar target, the latter is a candidate for updating the former.

If the target cache is enabled, each amake process starts a tcd process, which exits when its idle-timeout occurs. Thus, multiple tcd processes may be executing on multiple computers. They communicate with a single long-lived sqld process, which is probably started by some computer's rc sequence. They also access the target-cache filesystem, which is probably NFS-mounted during each computer's rc sequence. In any event, the sqld is assumed to be listening for connections from tcd processes, and the cache filesystem is assumed to be accessible by tcd processes. The sqld does not access the cache filesystem directly.

The sqld process manages an SQL database, which contains target metadata. The database is named tcd. It contains two tables, named entries and log. These are the schemas:

     create database tcd;
     use tcd;
     create table entries (
         date     varchar(20),
         name     text,
         arch     varchar(60),
         chksum   varchar(40),
         cmdsum   varchar(40),
         cachedir text
     );
     create table log (
         op       varchar(8),
         date     varchar(20),
         host     varchar(80),
         user     varchar(20),
         name     text,
         cwd      text,
         result   varchar(7)
     );

The cache filesystem holds cached files. They are stored below directories whose names prevent collisions. Directory names are constructed from: user name, host name, date, process number, and time.

Prior to rebuilding a target, an amake process's tcd process forks yet another process, to search 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, if any, are also stored in the cache filesystem, as a single tar file.