CHAPTER 10: Separate Compilation and Libraries

10.4 The Program Library

Associated with each program library there must be a file that records information relative to the compilations that have already been done. In particular, this file must contain symbol tables for separately compiled package specifications. It must also record compilation dates and dependence relations between compilation units: this information is used by the compiler for checking compilation order and for deciding which compilation units are affected by given recompilations.

When submitting a compilation unit to the compiler, the programmer provides:

• the source text of the compilation unit, and
• the name of the program library to which the unit is to belong.

For each Ada program we consider a single program library. In practice a given program library will often be formed from components obtained from other program libraries. The means for transferring components from one library to another are not properly within the domain of the Ada language but rather within that of its possible support environments [DoD 80]. The following facilities are expected:

Library creation

There should be commands for creating the program library of a given program, or of a given family of programs.

Inclusion of library units

There should be a command to include a unit of one library within another library. This process is similar to what is traditionally done for transferring the object code of a software component; in particular it can imply either making a copy or creating a new access path to a single (shared) copy. The only difference is that for Ada compilation units the information transferred includes descriptive information such as symbol tables, compilation dates, and dependence relations on other software components, and checks are made that no Ada rule is violated.

After its inclusion, a unit should be indistinguishable from other units of the library. Inclusion of a given compilation unit may require further inclusion of other compilation units that are needed by the given unit.

Deletion of library units

Conversely there should be a command to delete a unit from a given library.

Completion check

There should be a command by which a user states that the program is considered to be complete: all units should have been compiled by that time. The compiler will check that this is the case and issue appropriate error messages otherwise.

Status checks

There should be commands to display global information about the current state of the program library: which units have been compiled, which subunits have never been compiled, which units need to be recompiled, and so on.

Since the compiler is able to detect the need for recompilations, it could conceivably do these automatically upon detection of such a need. However, changes are often done for several units at the same time. A compiler that performed recompilations after each change might perform more recompilations than necessary unless it had global knowledge of all changes submitted.

Assume for example that the specifications of the packages A and B were modified. If all units that see A were automatically recompiled, then if some of them also see B, they would be recompiled a second time after the compilation of B.

Hence it is certainly preferable to let the user manage the recompilations. However, this means that tools for displaying the current status of compilation units of a program should be provided. Similarly it means that the user should be able to state that a program is complete and let the compiler check that this is actually the case.