You can place configuration pragmas either appear at the start of a compilation unit or in a configuration pragma file that applies to all compilations performed in a given compilation environment.
Configuration pragmas placed before a library level package specification are not propagated to the corresponding package body (see RM 10.1.5(8)); they must be added explicitly to the package body.
GNAT includes the gnatchop utility to provide an automatic
way to handle configuration pragmas that follows the semantics for
compilations (that is, files with multiple units) described in the RM.
See Operating gnatchop in Compilation Mode for details.
However, for most purposes, you will find it more convenient to edit the
gnat.adc file that contains configuration pragmas directly,
as described in the following section.
In the case of Restrictions pragmas appearing as configuration
pragmas in individual compilation units, the exact handling depends on
the type of restriction.
Restrictions that require partition-wide consistency (like
No_Tasking) are
recognized wherever they appear
and can be freely inherited, e.g. from a ‘with’ed unit to the ‘with’ing
unit. This makes sense since the binder will always insist on seeing
consistent us, so any unit not conforming to any restrictions
anywhere in the partition will be rejected and it’s better for you to find
that out at compile time rather than bind time.
For restrictions that do not require partition-wide consistency, e.g.
SPARK or No_Implementation_Attributes, the restriction
normally applies only to the unit in which the pragma appears, and not
to any other units.
The exception is No_Elaboration_Code, which always applies to the
entire object file from a compilation, i.e. to the body, spec, and all
subunits. You can apply this restriction in a configuration pragma
file or you can ace it in the body and/or the spec (in either case it
applies to all the relevant units). You can place it on a subunit only if
you have previously placed it in the body of spec.