A simple clearmake build scenario

clearmake is designed to let developers in makefile-based build environments continue working in their accustomed manner.

The following simple build scenario demonstrates how little adjustment is required to begin building with clearmake.

1. Set a view. Because working with HCL VersionVault data requires a view context, it makes sense to set a view before starting a build.

   (Strictly speaking, this is not required: if your process has a working directory view context, but not a set view context, clearmake sets the view to the working directory view by executing a cleartool setview -exec clearmake command. If your process has a working directory view context and a set view context, clearmake uses the working directory view.

2. Go to a development directory within any VOB.
3. Edit some source files. Typically, you need to edit some sources before performing a build; accordingly, you check out some file elements and revise the checked-out versions.
4. Start a build. You can use your existing makefiles, but start clearmake instead of your standard make program. For example:

   clearmake

   (build the default target)

   clearmake cwd.o libproj.lib

   (build one or more particular targets)

   clearmake -k monet CFLAGS=-g

   (use standard options and make-macro overrides)

(Avoid specifying make-macro overrides on the command line. For more information, see Specifying build options.)

clearmake builds targets (or avoids building them) in a manner similar to, but more sophisticated than, other make variants.

The following figure illustrates some typical build scenarios in which derived objects are rebuilt, reused, or winked in.

clearmake builds new derived objects for checked-out source files, reuses derived objects for checked-in source files that have previously built the object, and winks in derived objects from other views as appropriate for checked-in source files that have not previously built the object.

Note that clearmake does not attempt to verify that you have actually changed the file; the checkout makes a rebuild necessary. As you work, saving a file or invoking clearmake causes a rebuild of the dependents of the updated file, in the standard make manner.

For source files that you have not checked-out, clearmake might or might not build a new derived object:

• It might reuse a derived object that appears in your view, produced by a previous build.
• It might wink in an existing derived object built in another view. (It is even possible that a winked-in DO was originally created in your view, shared, and then deleted from your view, for example, by a make clean command.)
• Changes to other aspects of your build environment might trigger a clearmake rebuild: revision to a header file; change to the build script, use of a make-macro override; change to an environment variable used in the build script.