4.5.2.3 Elaboration Control

The following switches provide additional control over the elaboration order. For further details see Elaboration Order Handling in GNAT.

-f`elab-order'

Force elaboration order.

elab-order should be the name of a "forced elaboration order file", that is, a text file containing library item names, one per line. A name of the form "some.unit%s" or "some.unit (spec)" denotes the spec of Some.Unit. A name of the form "some.unit%b" or "some.unit (body)" denotes the body of Some.Unit. Each pair of lines is taken to mean that there is an elaboration dependence of the second line on the first. For example, if the file contains:

this (spec)
this (body)
that (spec)
that (body)

then the spec of This will be elaborated before the body of This, and the body of This will be elaborated before the spec of That, and the spec of That will be elaborated before the body of That. The first and last of these three dependences are already required by Ada rules, so this file is really just forcing the body of This to be elaborated before the spec of That.

The given order must be consistent with Ada rules, or else gnatbind will give elaboration cycle errors. For example, if you say x (body) should be elaborated before x (spec), there will be a cycle, because Ada rules require x (spec) to be elaborated before x (body); you can’t have the spec and body both elaborated before each other.

If you later add "with That;" to the body of This, there will be a cycle, in which case you should erase either "this (body)" or "that (spec)" from the above forced elaboration order file.

Blank lines and Ada-style comments are ignored. Unit names that do not exist in the program are ignored. Units in the GNAT predefined library are also ignored.

-p

Pessimistic elaboration order

This switch is only applicable to the pre-20.x legacy elaboration models. The post-20.x elaboration model uses a more informed approach of ordering the units.

Normally the binder attempts to choose an elaboration order that is likely to minimize the likelihood of an elaboration order error resulting in raising a Program_Error exception. This switch reverses the action of the binder, and requests that it deliberately choose an order that is likely to maximize the likelihood of an elaboration error. This is useful in ensuring portability and avoiding dependence on accidental fortuitous elaboration ordering.

Normally it only makes sense to use the -p switch if dynamic elaboration checking is used (-gnatE switch used for compilation). This is because in the default static elaboration mode, all necessary Elaborate and Elaborate_All pragmas are implicitly inserted. These implicit pragmas are still respected by the binder in -p mode, so a safe elaboration order is assured.

Note that -p is not intended for production use; it is more for debugging/experimental use.