3.4 Declaring Source Dependencies in Makefiles

To implement build avoidance based on time stamps, standard make variants require you to declare all the source file dependencies of each build target. For example, object module hello.obj depends on source files hello.c and hello.h in the same directory:

hello.obj: hello.c hello.h
del hello.obj
cl /c hello.c

Typically, these source files depend on project-specific header files through #include directives, perhaps nested within one another. The standard files do not change very often, but programmers often lament that "it didn't compile because someone changed the project's header files without telling me."

To alleviate this problem, some organizations include every header file dependency in their makefiles. They rely on utility programs to read the source files and determine the dependencies.

omake and clearmake do not require that source-file dependencies be declared in makefiles (but see Source Dependencies Declared Explicitly). The first time a derived object is built, its build script is always executed; thus, the dependency declarations are irrelevant for determining whether the target is out of date. After a derived object has been built, its configuration record provides a complete list of source-file dependencies used in the previous build, including those on all header files (nested and nonnested) read during the build.

NOTE: clearmake will rebuild a target if there have been changes to any directories listed as source-file dependencies.

You can leave source-file dependency declarations in your existing makefiles, but you need not update them as you revise the makefiles. And you need not place source-file dependencies in new makefiles to be used with omake or clearmake.

NOTE: Although source-file dependency declarations are not required, you may want to include them in your makefiles, anyway. The principal reason for doing so is portability: you may need to provide your sources to another team (or another company) that is not using ClearCase.

Source Dependencies Declared Explicitly

The ClearCase build auditing facility tracks only the MVFS objects used to build a target. Sometimes, however, you may want to track other objects. For example:

• The version of a compiler that is not stored in a VOB

• The version of the operating system kernel, which is not referenced at all during the build

• The state of a flag-file, used to force rebuilds

You can force such objects to be recorded in the CR by declaring them as dependencies of the makefile target:

hello.obj: hello.c hello.h my.flag
del hello.obj
cl /c hello.c

This example illustrates dependency declarations for these kinds of objects:

• (hello.c, hello.h) Dependencies on MVFS objects are optional. These are recorded by clearmake and MVFS anyway.

• my.flag - Dependencies on view-private objects can implement a flag-file capability.

Explicit Dependencies on Searched-For Sources

There are situations in which the configuration lookup algorithm that clearmake and omake use qualifies a derived object, even though rebuilding the target would produce a different result. Configuration lookup requires that for each object listed in an existing CR, the current view must select the same version of that object. However, in cases where you use search paths to find an object, a target rebuild may use a different object than the one listed in the CR. Configuration lookup does not take this possibility into account.

When files are accessed by explicit pathnames, configuration lookup qualifies derived objects correctly. Configuration lookup may qualify a derived object incorrectly if files are accessed at build time by a search through multiple directories, for example, when the -I option to a C or C++ compiler specifies a header file, or when the -L option to a linker specifies a library file. The following build script uses a search to locate a header file, fio.h:

hello.obj:
cl /c /I \projvob\privh /I \projvob\stdh hello.c

The command clearmake hello.obj may qualify an existing derived object built with C:\projvob\privh\fio.h, even though rebuilding the target would now use C:\projvob\stdh\fio.h instead.

omake and clearmake address this problem in the same way as some standard make implementations:

• You must declare the searched-for source object as an explicit dependency in the makefile:

hello.obj: fio.h
...

• You must use the VPATH macro to specify the set of directories to be searched:

VPATH = \projvob\privh;projvob\stdh

Given this makefile, omake (or clearmake) uses the VPATH (if any) when it performs configuration lookup on fio.h. If a candidate derived object was built with C:\projvob\privh\fio.h, but would be built with C:\projvob\stdh\fio.h in the current view, the candidate is rejected.

NOTE: The VPATH macro is not used for all source dependencies listed in the config record. It is used only for explicitly declared dependencies of the target. Also, clearmake searches only in the current view.

Build Tool Dependencies. You can use this mechanism to implement dependencies on build tools. For example, you can track the version of the C compiler used in a build as follows:

msg.obj: msg.c $(CC)
$(CC) /c msg.c

With this makefile, either your VPATH must include the directories on your search path, or you must use a full pathname as the $(CC) value.

NOTE: If your C compiler is stored in a VOB and you invoke it from the VOB, ClearCase tracks its version and you do not have to include it as a dependency.