Compiler Configuration File

Compiler Configuration File
Prev	Chapter 2. Using the Compiler	Next

In addition to command line options, configuration commands can be used to apply specific compiler options to specific items within a schema. These options can be applied to specific modules, productions, and elements as well as globally.

Configuration items may be specified in one or two ways (or a combination of both):

Using special comments embedded directly in an ASN.1 file, or
Using an external XML configuration file

A simple form of XML is used as the format for the configuration items. XML was chosen because it is fairly well known and provides a natural interface for representing hierarchical data such as the structure of ASN.1 modules and productions.

In the case of embeddeding directives directly in the ASN.1 source file, the directive is included as a comment directly before the item to which it is to be applied. For example:

   BackupBearerCapOctetGroup5 ::= SEQUENCE {
      octet5 BearerCapOctet5,
      --<end3GExtElem name="octet5.ext"/>
      octet5a BearerCapOctet5a
   }

In this case, the end3GExtElem configuration item would be applied to the octet5a element.

An external configuration file would target the item to which the directive is to be applied by specifying module, production, and element in an XML hierarchy. An example of this is as follows:

   <asn1config>
     <module name=”TS24008IES”>
       <production name=”BackupBearerCapOctetGroup5”>
         <element name=”octet5a”>
           <end3GExtElem name="octet5.ext"/>
         </element>
       </production>
     </module>
   </asn1config>

At the outer level of the markup is the <asn1config> </asn1config> tag pair. Within this tag pair, the specification of global items and modules can be made. Global items are applied to all items in all modules. An example would be the <storage> qualifier. A storage class such as dynamic can be specified and applied to all productions in all modules. This will cause dynamic storage (pointers) to be used for any embedded structures within all of the generated code to reduce memory consumption demands.

The specification of a module is done using the <module></module> tag pair. This tag pair can only be nested within the top-level <asn1config> section. The module is identified by using the required <name></name> tag pair or by specifying the name as an attribute (for example, <module name="MyModule">). Other attributes specified within the <module> section apply only to that module and not to other modules specified within the specification. A complete list of all module attributes is provided in the table at the end of this section.

The specification of an individual production is done using the <production></production> tag pair. This tag pair can only be nested within a <module> section. The production is identified by using the required <name></name> tag pair or by specifying the name as an attribute (for example, <production name="MyProd">). Other attributes within the production section apply only to the referenced production and nothing else. A complete list of attributes that can be applied to individual productions is provided in the table at the end of this section.

When an attribute is specified in more than one section, the most specific application is always used. For example, assume a <typePrefix> qualifier is used within a module specification to specify a prefix for all generated types in the module and another one is used to a specify a prefix for a single production. The production with the type prefix will be generated with the type prefix assigned to it and all other generated types will contain the type prefix assigned at the module level.

Values in the different sections can be specified in one of the following ways:

Using the <name>value</name> form. This assigns the given value to the given name. For example, the following would be used to specify the name of the "H323-MESSAGES" module in a module section:
```
   <name>H323-MESSAGES</name>
```
Flag variables that turn some attribute on or off would be specified using a single <name/> entry. For example, to specify a given production is a PDU, the following would be specified in a production section:
```
   <isPDU/>
```
An attribute list can be associated with some items. This is normally used as a shorthand form for specifying lists of names. For example, to specify a list of type names to be included in the generated code for a particular module, the following would be used:
```
   <include types="TypeName1,TypeName2,TypeName3"/>
```

The following are some examples of configuration specifications:

   <asn1config><storage>dynamic</storage></asn1config>

This specification indicates dynamic storage should be used in all places where its use would result in significant memory usage savings within all modules in the specified source file.

   <asn1config>
      <module>
         <name>H323-MESSAGES</name>
         <sourceFile>h225.asn</sourceFile>
         <typePrefix>H225</typePrefix>
      </module>
      ...
   </asn1config>

This specification applies to module ‘H323-MESSAGES’ in the source file being processed. For IMPORT statements involving this module, it indicates that the source file ‘h225.asn’ should be searched for specifications. It also indicates that when C or C++ types are generated, they should be prefixed with ‘H225’. This can help prevent name clashes if one or more modules are involved and they contain productions with common names.

The following tables specify the list of attributes that can be applied at all of the different levels: global, module, and individual production:

Prev	Up	Next
Porting Run-time Code to Other Platforms	Home	Global Level