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:
- It looks inside the archive
libvg.a
, and determines that it includes anout.o
that is older than its source file. - It compiles a new
out.o
fromout.c
. - It uses
ar
to incrementally updatelibvg.a
, replacing the old instance of object moduleout.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:
- It considers all the
libvg.a(...)
dependencies to be multiple instances of the same double-colon build target. - 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 archivelibvg.a
from scratch.
Thus, clearmake accepts the standard incremental-update syntax, but interprets it in a way that produces a non-incremental build procedure.