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.
Examples of Compilation Order:
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.