Makefile restructuring for incremental archive targets

Learn how to restructure makefile for incremental archive targets.

The makefile in the previous example can be restructured to allow incremental updates to an archive:

.INCREMENTAL_TARGET: libvg.a
libvg.a: base.o in.o out.o
   ar rv libvg.a $? 

base.o:
   cc -c base.c

in.o:
   cc -c in.c

out.o:
   cc -c out.c

Object modules built by this makefile are standard, shareable derived objects; typically, as library sources stabilize, most builds of target libvg.a reuse or wink in most of the object modules.

The .INCREMENTAL_TARGET directive tells clearmake to merge CRs incrementally for this target, that is, to merge the dependencies listed in the previous CR with those of the latest build. In this way, no information is lost from the CRs. Note that .INCREMENTAL_TARGET accepts patterns on its list of targets, as well as file names, so you can direct clearmake to merge all archive targets incrementally by including the directive .INCREMENTAL_TARGET: %.a in the makefile.

During a rebuild, the $? macro expands to the list of dependencies that do not match the current configuration record for the target. $? is useful in conjunction with ar r to replace, in the archive library, only those objects that have changed.

Avoid the following alternate restructuring; it causes a complete rebuild of the archive each time any object module is updated:

base.o: base.c 
   cc -c base.c
   ar rv libvg.a base.o
  .
  . and so on

Note: When you use .INCREMENTAL_TARGET with an archive library, the full set of declared dependencies must be the same in all makefiles that update that library. Do not attempt to build up libraries incrementally from two different makefiles. For example:

../lib.a: base.o: (makefile 1)
ar rv ../lib.a base.o
../lib.a: in.o out.o: (makefile 2)
ar rv ../lib.a in.o out.o

The rules are executed in multiple steps, and clearmake does not combine them to verify that the target is up to date with respect to all of its dependencies. Using the preceding construction given can result in missing required rebuilds (with either make or clearmake).

A note on the use of ar keys

Do not use the u key with ar; it is not reliable within an HCL VersionVault environment.

The r key might be used to direct ar to replace one or more object modules in an archive library without replacing the entire library. The u key directs ar to replace only those object modules with modification dates more recent than the archive library.

This behavior creates problems within VersionVault. When determining whether a .o file needs to be rearchived, ar looks only at whether its time stamp is older than that of the .a file. This check is not sufficient to determine whether a file inside a VersionVault VOB is out of date. For example, a build winks in a .o file whose time stamp is older than the time stamp of the .a file. Because the file is different from the one used the last time you built the archive, you want the file to be rearchived. However, because ar sees that the time stamp is older, it does not rearchive the .o file.