GNAT GPL User's Guide: Configuration Pragmas

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# 9. Configuration Pragmas

> 9.1 Handling of Configuration Pragmas |  |
> 9.2 The Configuration Pragmas Files |  |

Configuration pragmas include those pragmas described as such in the Ada Reference Manual, as well as implementation-dependent pragmas that are configuration pragmas. See section `Implementation Defined Pragmas' in GNAT Reference Manual, for details on these additional GNAT-specific configuration pragmas. Most notably, the pragma `Source_File_Name`, which allows specifying non-default names for source files, is a configuration pragma. The following is a complete list of configuration pragmas recognized by GNAT:

       Ada_83
       Ada_95
       Ada_05
       Ada_2005
       Ada_12
       Ada_2012
       Allow_Integer_Address
       Annotate
       Assertion_Policy
       Assume_No_Invalid_Values
       C_Pass_By_Copy
       Check_Name
       Check_Policy
       Compile_Time_Error
       Compile_Time_Warning
       Compiler_Unit
       Component_Alignment
       Convention_Identifier
       Debug_Policy
       Detect_Blocking
       Default_Storage_Pool
       Discard_Names
       Elaboration_Checks
       Eliminate
       Extend_System
       Extensions_Allowed
       External_Name_Casing
       Fast_Math
       Favor_Top_Level
       Float_Representation
       Implicit_Packing
       Initialize_Scalars
       Interrupt_State
       License
       Locking_Policy
       Long_Float
       No_Run_Time
       No_Strict_Aliasing
       Normalize_Scalars
       Optimize_Alignment
       Persistent_BSS
       Polling
       Priority_Specific_Dispatching
       Profile
       Profile_Warnings
       Propagate_Exceptions
       Queuing_Policy
       Ravenscar
       Restricted_Run_Time
       Restrictions
       Restrictions_Warnings
       Reviewable
       Short_Circuit_And_Or
       Source_File_Name
       Source_File_Name_Project
       SPARK_Mode
       Style_Checks
       Suppress
       Suppress_Exception_Locations
       Task_Dispatching_Policy
       Universal_Data
       Unsuppress
       Use_VADS_Size
       Validity_Checks
       Warnings
       Wide_Character_Encoding

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 9.1 Handling of Configuration Pragmas

Configuration pragmas may either appear at the start of a compilation unit, or they can appear in a configuration pragma file to apply to all compilations performed in a given compilation environment.

GNAT also provides the `gnatchop` utility to provide an automatic way to handle configuration pragmas following the semantics for compilations (that is, files with multiple units), described in the RM. See 8.2 Operating gnatchop in Compilation Mode for details. However, for most purposes, it will be 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 in any case insist on seeing consistent use, so any unit not conforming to any restrictions that are anywhere in the partition will be rejected, and you might as well find that out at compile time rather than at bind time.

For restrictions that do not require partition-wide consistency, e.g. SPARK or No_Implementation_Attributes, in general the restriction 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. This restriction can be specified in a configuration pragma file, or it can be on the body and/or the spec (in eithe case it applies to all the relevant units). It can appear on a subunit only if it has previously appeared in the body of spec.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 9.2 The Configuration Pragmas Files

In GNAT a compilation environment is defined by the current directory at the time that a compile command is given. This current directory is searched for a file whose name is ``gnat.adc'`. If this file is present, it is expected to contain one or more configuration pragmas that will be applied to the current compilation. However, if the switch ``-gnatA'` is used, ``gnat.adc'` is not considered. When taken into account, ``gnat.adc'` is added to the dependencies, so that if ``gnat.adc'` is modified later, an invocation of `gnatmake` will recompile the source.

Configuration pragmas may be entered into the ``gnat.adc'` file either by running `gnatchop` on a source file that consists only of configuration pragmas, or more conveniently by direct editing of the ``gnat.adc'` file, which is a standard format source file.

In addition to ``gnat.adc'`, additional files containing configuration pragmas may be applied to the current compilation using the switch ``-gnatec='`path. path must designate an existing file that contains only configuration pragmas. These configuration pragmas are in addition to those found in ``gnat.adc'` (provided ``gnat.adc'` is present and switch ``-gnatA'` is not used).

It is allowable to specify several switches ``-gnatec='`, all of which will be taken into account.

Files containing configuration pragmas specified with switches ``-gnatec='` are added to the dependencies, unless they contain only pragmas Source_File_Name_Project.

If you are using project file, a separate mechanism is provided using project attributes, see 12.1.3 Specifying Configuration Pragmas for more details.

[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by GNAT Mailserver on April, 17 2014 using texi2html