Ada '83 Language Reference Manual

Copyright 1980, 1982, 1983 owned by the United States Government. Direct reproduction and usage requests to the Ada Information Clearinghouse.

10.3. Order of Compilation

The rules defining the order in which units can be compiled are direct consequences of the visibility rules and, in particular, of the fact that any library unit that is mentioned by the context clause of a compilation unit is visible in the compilation unit.

A compilation unit must be compiled after all library units named by its context clause. A secondary unit that is a subprogram or package body must be compiled after the corresponding library unit. Any subunit of a parent compilation unit must be compiled after the parent compilation unit.

If any error is detected while attempting to compile a compilation unit, then the attempted compilation is rejected and it has no effect whatsoever on the program library; the same holds for recompilations (no compilation unit can become obsolete because of such a recompilation).

The order in which the compilation units of a program are compiled must be consistent with the partial ordering defined by the above rules.

Similar rules apply for recompilations. A compilation unit is potentially affected by a change in any library unit named by its context clause. A secondary unit is potentially affected by a change in the corresponding library unit. The subunits of a parent compilation unit are potentially affected by a change of the parent compilation unit. If a compilation unit is successfully recompiled, the compilation units potentially affected by this change are obsolete and must be recompiled unless they are no longer needed. An implementation may be able to reduce the compilation costs if it can deduce that some of the potentially affected units are not actually affected by the change.

The subunits of a unit can be recompiled without affecting the unit itself. Similarly, changes in a subprogram or package body do not affect other compilation units (apart from the subunits of the body) since these compilation units only have access to the subprogram or package specification. An implementation is only allowed to deviate from this rule for inline inclusions, for certain compiler optimizations, and for certain implementations of generic program units, as described below.

• If a pragma INLINE is applied to a subprogram declaration given in a package specification, inline inclusion will only be achieved if the package body is compiled before units calling the subprogram. In such a case, inline inclusion creates a dependence of the calling unit on the package body, and the compiler must recognize this dependence when deciding on the need for recompilation. If a calling unit is compiled before the package body, the pragma may be ignored by the compiler for such calls (a warning that inline inclusion was not achieved may be issued). Similar considerations apply to a separately compiled subprogram for which an INLINE pragma is specified.
  
  
• For optimization purposes, an implementation may compile several units of a given compilation in a way that creates further dependences among these compilation units. The compiler must then take these dependences into account when deciding on the need for recompilations.
  
  
• An implementation may require that a generic declaration and the corresponding proper body be part of the same compilation, whether the generic unit is itself separately compiled or is local to another compilation unit. An implementation may also require that subunits of a generic unit be part of the same compilation.

Examples of Compilation Order:

1. In example 1 (see 10.1.1): The procedure QUADRATIC_EQUATION must be compiled after the library packages TEXT_IO and REAL_OPERATIONS since they appear in its with clause.
   
   
2. In example 2 (see 10.1.2): The package body STOCK must be compiled after the corresponding package specification.
   
   
3. In example 2 (see 10.1.2): The specification of the package STOCK must be compiled before the procedure PROCESSOR. On the other hand, the procedure PROCESSOR can be compiled either before or after the package body STOCK.
   
   
4. In example 3 (see 10.2.1): The procedure G must be compiled after the package TEXT_IO since this package is named by the with clause of G. On the other hand, TEXT_IO can be compiled either before or after TOP.
   
   
5. In example 3 (see 10.2.1): The subunits TRANSFORM and FACILITY must be compiled after the main program TOP. Similarly, the subunit G must be compiled after its parent unit FACILITY.

For library packages, it follows from the recompilation rules that a package body is made obsolete by the recompilation of the corresponding specification. If the new package specification is such that a package body is not required (that is, if the package specification does not contain the declaration of a program unit), then the recompilation of a body for this package is not required. In any case, the obsolete package body must not be used and can therefore be deleted from the program library.

References: compilation, compilation unit, context clause, elaboration, generic body, generic declaration, generic unit, library unit, local declaration, name, package, package body, package specification, parent unit, pragma inline, procedure, procedure body, proper body, secondary unit, subprogram body, subprogram declaration, subprogram specification, subunit, type, variable, visibility, with clause.

Address any questions or comments to adainfo@sw-eng.falls-church.va.us.