2.1 The omake Process

omake works in two distinct phases:

• read time, when it reads the files (called makefiles) that provide it with a project description

• run time, when it builds the project

A project consists of one or more targets. A target is a thing that can be made, usually a file, such as a source file, object file, or executable file. The target is said to exist if the file is present on disk. The pathname to a target is its location on disk. The target's configuration record (CR) is a software bill of materials record that fully documents the build of the target and supports omake's ability to rebuild. The CR includes the following information:

• Which MVFS file system objects (and which versions of those objects) were used by the build as input data

• The commands used to perform the build

• Which MVFS files were created as output

The target's time stamp is the time the target was last changed. This is usually the creation or modification time of the file.

Reading the makefiles gives omake dependency information. A dependency is the relationship between a target and the things needed to make it. For example, an executable file that is linked from a set of object files must be relinked if any of the object files change; thus, the executable file depends on the object files. One way to think of this dependency information is as a data tree, which may be several levels deep. For example, an executable proj.exe may depend on main.obj and io.obj, each of which depend on source files main.c and io.c, respectively.

The things a target depends on are its dependencies. In fact, dependencies are also targets because they can be (and are) made.

To make or build a target means to bring it up to date. A build script (sometimes referred to as a shell line) is a command that omake executes to bring a target up to date. For example, a link command updates an executable file. The command returns an exit status, which lets omake know whether it succeeded. If the command succeeds, omake generates and stores a configuration record. This configuration record is attached to each file modified or created by executing the build script. A file produced by the build and associated with a configuration record is called a derived object (DO).

If the target (derived object) is located in the MVFS, omake uses configuration lookup to determine whether it is necessary to rebuild a derived object by executing a build script or by reusing an existing instance of the derived object. omake traverses the dependency tree and compares the configuration record of each target to the build configuration of the current view (the set of dependency versions, the current build script, and the current build options), rebuilding the target if necessary. For each target, the tree is traversed to the bottom and back up.

If the target is not in a VOB, omake compares the time stamp of the target to those of its dependencies. If the target is older than any of its dependencies, omake rebuilds it.

Note that if you are working in a snapshot view, omake does not perform configuration lookup and it does not create derived objects or configuration records. For more information about snapshot views, see Developing Software.

NOTE: In this chapter, the examples assume that the files are in a VOB.