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
.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.