The previous chapter has been concerned with the static side of ComPact, since it has described what you need to know of software packages to actually start working; Section 5.1 and Section 5.2 of this chapter are concerned with the dynamic side of that, since they supplement what commands from the area of build management you probably need to know of initially. Afterward, Section 5.4 and Section 5.5 go through the remainder of that what can be said with regard to build management without venturing into the other aspects of ComPact's functionality.
Commands Working on Unique Packages: On a preliminary note, this chapter and Chapter 6 and Chapter 7 are almost soleley concerned with pkgm commands that operate on a unique package, which is called the local package. The specific command in question must always be given from within or below that package's root directory.
Initialization: On another preliminary note, each invocation of pkgm is initialized in the following way:
An initialization file is searched according to the search path stated in Chapter 2. If no one can be found, an error message is displayed as soon as some setting is needed. You should see no such message when you have invoked pkgm with a command option of -help, -man, -copyright, -syntax, or -gsyntax.
The root directory of the local package is located. If it is not found, an error message is displayed.
If necessary, the target-platform-configuration information is searched in the configuration resource path and the hard-wired configurations (see Chapter 6). If it is not found, an error message is displayed.
If necessary, the directory structure of each individual package pool is cached.
The synopsis of the build command is as follows:
[ -build ] [ build_options ] [ target_name+ ]
As mentioned earlier, this one is the default command, so the command option, -build, may be omitted. Moreover, build options can be used to shorten the build process when appropriate (see below), and the optional list may be used to restrict it to specific targets. In the absence of any TPC-dependencies, the default is to build all of them.
More on Dependency Computation: It was also mentioned earlier that an essential part of the build process consists of exploiting direct dependencies within the local package. More specifically, each library or program is directly dependent on each object file that is necessary to create it; each object file is directly dependent on its source code file f, say, and on each header file included in f.
Important: ComPact retrieves this information, stores it, and uses it, before it builds a target, to re-compile every relevant object file that is older then any file it directly depends on. In consequence, the target built is up-to-date.
The structure of the entire build process, then, is such that ComPact checks the consistency of the local package, and whether it can find all imported packages. If everything is okay, any necessary dependency re-computation is accomplished. Then compiler and linker are invoked as necessary to construct the desired target(s).
Furthermore, the above-mentioned build options are as follows:
Table 5-1.
| -noautodep | -nodep | do not re-compute any dependencies |
| -nohooks | -nh | do not execute any hook commands |
| before or after building the target(s) |
In keeping with the consistency control approach, all of the exported elements of the local package may be shipped to some pool once a target has been sucessfully built:
-ship [ local ] # default pool -ship ( project | global )This synopsis of -ship, however, is simplified. The reason is that shipping on a project-wide or global scale is somewhat problematic if there is no active version control. The full synopsis of -ship can be found in Chapter 7.