[Home] [Prev] [Next] [Index]

10.3 Order of Compilation

10.3 Order of Compilation

1
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.

2
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.

3
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).

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

5
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.

6
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.

7 ·
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.

8 ·
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.

9 ·
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.

10
Examples of Compilation Order:

11 (a)
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.

12 (b)
In example 2 (see 10.1.2): The package body STOCK must be compiled after the corresponding package specification.

13 (c)
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.

14 (d)
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.

15 (e)
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.

Notes:

16
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.

17
References:

*
compilation 10.1

*
compilation unit 10.1

*
context clause 10.1.1

*
elaboration 3.9

*
generic body 12.2

*
generic declaration 12.1

*
generic unit 12

*
library unit 10.1

*
local declaration 8.1

*
name 4.1

*
package 7

*
package body 7.1

*
package specification 7.1

*
parent unit 10.2

*
pragma inline 6.3.2

*
procedure 6.1

*
procedure body 6.3

*
proper body 3.9

*
secondary unit 10.1

*
subprogram body 6.3

*
subprogram declaration 6.1

*
subprogram specification 6.1

*
subunit 10.2

*
type 3.3

*
variable 3.2.1

*
visibility 8.3

*
with clause 10.1.1



[Home] [Prev] [Next] [Index]

documentation@rational.com
Copyright © 1993-2000, Rational Software Corporation. All rights reserved.