2.7 Source Dependencies

A given object file clearly depends on the source file which is compiled to produce it. Here we are using depends in the sense of a typical make utility; in other words, an object file depends on a source file if changes to the source file require the object file to be recompiled. In addition to this basic dependency, a given object may depend on additional source files as follows:

• If a file being compiled with's a unit X, the object file depends on the file containing the spec of unit X. This includes files that are with'ed implicitly either because they are parents of with'ed child units or they are run-time units required by the language constructs used in a particular unit.
• If a file being compiled instantiates a library level generic unit, the object file depends on both the spec and body files for this generic unit.
• If a file being compiled instantiates a generic unit defined within a package, the object file depends on the body file for the package as well as the spec file.
• If a file being compiled contains a call to a subprogram for which pragma Inline applies and inlining is activated with the -gnatn switch, the object file depends on the file containing the body of this subprogram as well as on the file containing the spec. Note that for inlining to actually occur as a result of the use of this switch, it is necessary to compile in optimizing mode.

  The use of -gnatN activates inlining optimization that is performed by the front end of the compiler. This inlining does not require that the code generation be optimized. Like -gnatn, the use of this switch generates additional dependencies. Note that -gnatN automatically implies -gnatn so it is not necessary to specify both options.

  When using a gcc-based back end (in practice this means using any version of GNAT other than the JGNAT, .NET or GNAAMP versions), then the use of -gnatN is deprecated, and the use of -gnatn is preferred. Historically front end inlining was more extensive than the gcc back end inlining, but that is no longer the case.

• If an object file O depends on the proper body of a subunit through inlining or instantiation, it depends on the parent unit of the subunit. This means that any modification of the parent unit or one of its subunits affects the compilation of O.
• The object file for a parent unit depends on all its subunit body files.
• The previous two rules meant that for purposes of computing dependencies and recompilation, a body and all its subunits are treated as an indivisible whole.

  These rules are applied transitively: if unit A with's unit B, whose elaboration calls an inlined procedure in package C, the object file for unit A will depend on the body of C, in file c.adb.

  The set of dependent files described by these rules includes all the files on which the unit is semantically dependent, as dictated by the Ada language standard. However, it is a superset of what the standard describes, because it includes generic, inline, and subunit dependencies.

  An object file must be recreated by recompiling the corresponding source file if any of the source files on which it depends are modified. For example, if the make utility is used to control compilation, the rule for an Ada object file must mention all the source files on which the object file depends, according to the above definition. The determination of the necessary recompilations is done automatically when one uses gnatmake.