Example: building an archive

A common incremental-update scenario is the building of an archive by ar(1).

A traditional make program treats an archive as a compound object; it can examine the time stamps of the individual components (object modules) in the archive; and it can update the archive by replacing one or more individual object modules. Here is a simple makefile in which a special syntax enables multiple targets to update a single archive, libvg.a, incrementally:

libvg.a:: libvg.a(base.o)
libvg.a:: libvg.a(in.o)
libvg.a:: libvg.a(out.o)

If you edit one of the library's sources (for example, out.c), a traditional make program uses the special syntax and a .c.a built-in rule to update the library as follows:

  1. It looks inside the archive libvg.a, and determines that it includes an out.o that is older than its source file.
  2. It compiles a new out.o from out.c.
  3. It uses ar to incrementally update libvg.a, replacing the old instance of object module out.o with the newly built instance.

clearmake does not implement this algorithm and includes no support for treating an archive as a compound object. HCL VersionVault build-avoidance is based solely on metadata (CRs), not on any analysis of the file system data. clearmake interprets the above makefile as follows:

  1. It considers all the libvg.a(...) dependencies to be multiple instances of the same double-colon build target.
  2. Accordingly, whenever one of those double-colon targets requires rebuilding, clearmake rebuilds them all, using the standard .c.a built-in rule. The effect is to rebuild the entire archive libvg.a from scratch.

Thus, clearmake accepts the standard incremental-update syntax, but interprets it in a way that produces a non-incremental build procedure.