![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Defining Basic Characteristics This chapter describes the basic operating characteristics that you must define for your customization. It includes the characteristics that describe package Standard, the remote operating system, and the target compilation system. Using the instructions in this chapter, you will be able to define compiler, operating system, and package Standard characteristics for a basic customization.
This chapter expands on the steps to create a customized RCI that were presented in Building A Basic Customization.
This section describes the following areas of the customization process:
- Defining Package Standard Values
- Defining Operational Characteristics
- Defining Target Compilation Rules
- Defining Target Command Properties
- Defining Target Compiler and Linker Options
- Defining Target Operational Data
Note: Rational may be able to provide additional information to help with customization for a particular target compilation platform or vendor compiler. Before you begin a customization, contact your Rational representative for more information.
Defining Package Standard ValuesThis section describes how to define target compiler values in package Standard for semantic checking by the host.
To create the definition for package Standard, modify the file rci_predef.spec in the compiler key to specify the correct integer, float, and fixed types. The RCI automatically builds package Standard from the lists of objects when you code an Ada unit in a view which imports your LRM view if it has not previously been built. If you want to force the compiler to rebuild standard, clean the file standard_.1.ada in your LRM view. This can be a useful step during incremental development of your customizations rci_predef.spec file.
What Information to Gather
- Compiler Guide and Reference for your target compiler
- Operating System Guide and Reference for your target compilation platform
- LRM, Appendix F for your target compiler
- Package Standard for your target compiler
- comp.spec in your rci.ss view
- rci_predef.spec from one of the sample customizations
RCI Specification Language
RCI Specification Language is used for all of the specification files starting with Apex 3.0. We suggest that you use an editor with a parentheses balancing feature (Emacs is one such editor, and it is provided with Apex).
RCI Spec language is defined in the file comp.spec in your rci.ss view. The language has a simple, fixed format, where each production is completed inside a set of parentheses, leading to nested parenthetical expressions.
The overall format of any RCI specification file is shown in Figure 3, and an example of the rci_predef.spec file is shown in Figure 4.
Figure 3 Top Level Structure of an RCI Specification
( RCI_CUSTOMIZATION <ADA_83 | ADA_95> #id# < ( PREDEFINED ...) | ( PRAGMAS ...) | ( ATTRIBUTES ...) | ( REP_SPECS ...) | ( OPERATIONAL_INFO ...) > )There are five RCI Specification files which are part of a customization, corresponding with the five alternatives shown in Figure 3 above (rci_predef.spec, rci_pragmas.spec, rci_attrib.spec, rci_rep_specs.spec and rci_op.spec). Each specification file should have the structure shown above.
RCI Specification Language Notation
In figures which show RCI Specification Language,
- [] delimits an optional component,
- {} delimits a component which may have 0 or more instances,
- <> delimits a list of alternatives,
- | separates alternatives,
- ## delimits the type of a literal that should appear at that point in the expression. strings must be double quoted ("a string").
- #id# is a special case: it indicates an double quoted identifier that follows Ada syntax should appear at the given point.
- Components which end with an ellipsis (...) are defined elsewhere, possibly later in the figure.
- Parentheses are part of the language and should appear in the specification file as shown. Formatting of the parenthetical expressions is optional, and in the examples shown in this manual the final parenthesis may be shown after the final component, or brought out to top level as in the example below.
- Lower case identifiers are component names which are defined in a different figure.
Editing the Specification for Package Standard
The specification for Package Standard is built in the file rci_predef.spec in the compiler key.
An example of the rci_predef.spec file is shown by a simple example in Figure 4.
Figure 4 Example Package Standard Specification
( RCI_CUSTOMIZATION ADA_83 VADS ( PREDEFINED (INTEGERS ...) (FLOATS ...) (FIXEDS ...) [USE_LATIN_1] ) )Defining Integers
This section describes the specification of the integer types defined by the target compiler package Standard.
For each integer type you need to define, fill in the production for integer descriptor as shown in Figure 5, then take a look at the completed examples in the rci_predef.spec file included in the VADS and GNAT example customizations.
Figure 5 Integer Descriptor
( INTEGERS { ( INTEGER_DESCRIPTOR #id# SIZE #natural# LO_BOUND #string# HI_BOUND #string# ) } )Provide the following values for each integer type T:
- Id: String: name of T from the LRM.
- Size: Natural: T'Base'Size.
- Lo_Bound/Hi_bound: String: string of digits that represent T'Base'First and T'Base'Last.
Example Integer Types Specification
Figure 6 shows the integer types specification for the VADS example customization.
Figure 6 Example Integer Types Specification
( INTEGERS ( INTEGER_DESCRIPTOR "TINY_INTEGER" SIZE 8 LO_BOUND "-128" HI_BOUND "127" ) ( INTEGER_DESCRIPTOR "SHORT_INTEGER" SIZE 16 LO_BOUND "-32768" HI_BOUND "32767" ) ( INTEGER_DESCRIPTOR "INTEGER SIZE 32 LO_BOUND "-2147483648" HI_BOUND "2147483647" ) ( INTEGER_DESCRIPTOR "LONG_INTEGER" SIZE 32 LO_BOUND "-2147483648" HI_BOUND "2147483647" ) ( INTEGER_DESCRIPTOR "RCI_UNSIGNED_INTEGER" SIZE 32 LO_BOUND "0" HI_BOUND "2147483647" ))Defining Floating Point Numbers
This section describes the specification of the floating point types defined by the target compiler package Standard.
For each floating point type you need to define, fill in the productions for float descriptor as shown in Step 7 and Figure 8, then take a look at the completed examples in the rci_predef.spec file included in the VADS and GNAT example customizations. Note that the two figures illustrate two kinds of floating point type specifications: IEEE floats (for which the characteristics can be computed by the Apex Ada compiler) and non-IEEE floats (for which the characteristics must be specified).
Figure 7 IEEE Floating Point Types Specification
( FLOATS { ( FLOAT_DESCRIPTOR #id# SIZE #positive# IS_IEEE [MACHINE_ROUNDS] [MACHINE_OVERFLOWS] [DENORM] [SIGNED_ZEROS] ) } )Note: IEEE floats must have sizes 32 or 64.
Figure 8 Non-IEEE Floating Point Type Specification
(FLOATS { ( FLOAT_DESCRIPTOR #id# SIZE #positive# DIGITZ #positive# LO_BOUND #string# HI_BOUND #string# SAFE_EMAX #integer# MACHINE_EMAX #integer# MACHINE_EMIN #integer# MACHINE_RADIX #positive# MACHINE_MANTISSA #positive# [MACHINE_ROUNDS] [MACHINE_OVERFLOWS] [DENORM] [SIGNED_ZEROS] ) } )Provide the following values for each non-IEEE floating point type T:
- Id: String: name of T from the LRM.
- Digitz: Positive: T'Base'Digits.
- Size: Positive: T'Base'Size.
- Lo_Bound/Hi_bound: String: string of digits that represent T'Base'First and T'Base'Last.
- The following values need to be set accurately only if users are going to use the corresponding LRM attributes for the given float type in expressions that are required to be static:
- Safe_Emax: Integer (T'Base'Safe_Emax)
- Machine_Emax: Integer (T'Base'Machine_Emax)
- Machine_Radix: Positive (T'Base'Machine_Radix)
- Machine_Mantissa: Positive (T'Base'Machine_Mantissa)
- Machine_Rounds (if T'Base'Machine_Rounds is true, include this field in your type descriptor)
- Machine_Overflows (if T'Base'Machine_Overflows is true, include this field in your type descriptor)
- Denorm (for Ada_95: if T'Base'Denorm is true, include this field in your type descriptor)
- Signed_Zeros (for Ada_95: if T'Base'Signed_Zeros is true, include this field in your type descriptor)
Example Floating Point Types Specification
The following example shows the floating point types specification for the VADS example customization. Figure 9 shows the specification without making the simplification that the floats are all IEEE. Figure 11 shows the specification that actually is used in the VADS customization.
Figure 9 Example Non-IEEE Floating Point Types Specification
( FLOATS ( FLOAT_DESCRIPTOR "SHORT_FLOAT" SIZE 32 DIGITZ 6 LO_BOUND "-340282346638528859811704183484516925440.0" HI_BOUND "340282346638528859811704183484516925440.0" SAFE_EMAX 125 MACHINE_EMAX 128 MACHINE_EMIN -125 MACHINE_RADIX 2 MACHINE_MANTISSA 24 MACHINE_ROUNDS MACHINE_OVERFLOWS SIGNED_ZEROS ) ( FLOAT_DESCRIPTOR "LONG_FLOAT" SIZE 64 DIGITZ 15 LO_BOUND
"-17976931348623157081452742373170435679807056752584499659891747 6803157260780028538760589558632766878171540458953514382464234321 3268894641827684675467035375169860499105765512820762454900903893 2894407586850845513394230458323690322294816580855933212334827479 7826204144723168738177180919299881250404026184124858368.0"
HI_BOUND
"179769313486231570814527423731704356798070567525844996598917476 8031572607800285387605895586327668781715404589535143824642343213 2688946418276846754670353751698604991057655128207624549009038932 8944075868508455133942304583236903222948165808559332123348274797 826204144723168738177180919299881250404026184124858368.0"
SAFE_EMAX 1021 MACHINE_EMAX 1024 MACHINE_EMIN -1021 MACHINE_RADIX 2 MACHINE_MANTISSA 53 MACHINE_ROUNDS MACHINE_OVERFLOWS SIGNED_ZEROS )
Figure 10 Example Non-IEEE Floating Point Types Specification, Cont.
( FLOAT_DESCRIPTOR "FLOAT" SIZE 32 DIGITZ 6 LO_BOUND "-340282346638528859811704183484516925440.0" HI_BOUND "340282346638528859811704183484516925440.0" SAFE_EMAX 125 MACHINE_EMAX 128 MACHINE_EMIN -125 MACHINE_RADIX 2 MACHINE_MANTISSA 24 MACHINE_ROUNDS MACHINE_OVERFLOWS SIGNED_ZEROS )
)Figure 11 Example IEEE Floating Point Types Specification
( FLOATS ( FLOAT_DESCRIPTOR "SHORT_FLOAT" SIZE 32 IS_IEEE MACHINE_ROUNDS MACHINE_OVERFLOWS SIGNED_ZEROS ) ( FLOAT_DESCRIPTOR "LONG_FLOAT" SIZE 64 IS_IEEE MACHINE_ROUNDS MACHINE_OVERFLOWS SIGNED_ZEROS ) ( FLOAT_DESCRIPTOR "FLOAT" SIZE 32 IS_IEEE MACHINE_ROUNDS MACHINE_OVERFLOWS SIGNED_ZEROS ) )Defining Fixed Point Numbers
This section describes the specification of the fixed point types defined by the target compiler package Standard.
Note: Duration is the only type you need to define.
For each fixed point type you need to define, fill in the productions for fixed descriptor as shown in Figure 12, then take a look at the completed examples in the rci_predef.spec file included in the VADS and GNAT example customizations.
Figure 12 Fixed Point Type Specification
( FIXEDS { ( FIXED_DESCRIPTOR #id# SIZE #natural# SCALE #integer# LO_BOUND #string# HI_BOUND #string# MACHINE_RADIX #positive# ) } )Provide the following values for each fixed point type T:
- Id: String: name of the type ("duration").
- Size: Natural: T'Base'Size.
- Scale: Integer: fixed_point_type'actual_delta = 2**Scale. Setting Scale to 0 corresponds to an actual delta of 1.
- Lo_Bound/Hi_Bound: String: string of digits that represent T'Base'First and T'Base'Last.
Example Fixed Point Types Specification
Figure 13 shows the fixed point types specification for the VADS example customization.
Figure 13 Example Fixed Point Types Specification
( FIXEDS ( FIXED_DESCRIPTOR "DURATION" SIZE 32 SCALE -13 LO_BOUND "-214748.3648" HI_BOUND "214748.3647" MACHINE_RADIX 2 ) )Completing Your Specification for Package Standard
If your target compiler supports the used of Latin 1 characters then be sure and include USE_LATIN_1 in your specification for package standard after your declaration of integer types, floating point types and fixed point types. See Figure 4.
Testing Your Specification for Package Standard
When you have finished editing rci_predef.spec, you can test it for syntax by running the following command (in an Apex shell):
% apex check_rci_specification \ -directory <compiler_key> \ -rci_prevent_buildAfter editing rci_predef.spec and rebuilding standard, analyze a unit in an RCI view (with the correct model and compiler key) which declares an integer variable. Visit the integer type to ensure that it takes you to the correct Standard and that your changes took place.
Updating Package Standard
As you use your customization, you may need to make changes to the predefined characteristics, to add new types or to change declarations for existing types.
- 1 . Edit the file rci_predef.spec in the compiler key.
- 2 . In your lrm.ss view, clean standard_.1.ada.
- 3 . In your lrm.ss view, code package System. This causes the Apex Ada compiler to build package Standard.
Defining Operational CharacteristicsWhat Information to Gather
- Target Compiler Guide and Reference for your target compiler
- Operating System Guide and Reference for your target compilation platform
- LRM, Appendix F for your target compiler
- comp.spec in your rci.ss view
- rci_op.spec from one of the sample customizations
Editing the Operational Characteristics Specification
Operational Characteristics include compilation rules command properties, compiler options and operational_data.
The specification for Operational Characteristics is built in the file rci_op.spec in the compiler key.
The overall format of the rci_op.spec file is shown in Figure 14, followed by definitions of each of the component parts of operational characteristics.
Figure 14 Top Level Structure of an Ada 83 Operational Characteristics Specification
( RCI_CUSTOMIZATION ADA_83 VADS ( COMPILATION_RULES ...) ( COMMAND_PROPS ...) ( COMPILER_OPTIONS ...) ( OPERATIONAL_DATA ...) )
Defining Target Compilation RulesThis section describes how to set the compilation rules in the file rci_op.spec. The compilation rules are included in the file rci_op.spec in your compiler key.
The production for compilation rules is shown in Figure 15.
Figure 15 Compilation Rules Specification
( COMPILATION_RULES [GENERICS_SHARE_CODE] [REQUIRE_BODY_AND_GENERIC_IN_SAME_COMPILATION] [REQUIRES_SUBUNITS_AND_GENERIC_IN_SAME_COMPILATION] [IMPLEMENTS_PRAGMA_INLINE] [SEPARATE_SUBUNITS_ARE_INEFFICIENT] [SPECS_CAN_BE_CODED] [GENERICS_CAN_BE_CODED] COMPILATION_MODE < INTERACTIVE | BATCH > ) )Definitions for each of the components of the Compilation Rules Specification follow. Include each rule in your specification only if it applies:
- Generics_Share_Code:
Blocks target recompilation of generic instantiations due to changes in the generic body.
Must be implemented in customization scripts.- Require_Body_and_Generic_In_Same_Compilation:
Causes a generic and its body to be gathered into one file when the generic is downloaded. Computation of recompilation order will take this repackaging into account.
Causes compiler to call customization script rci_group_compile during compilation of a generic spec.- Requires_Subunits_And_Generic_In_Same_Compilation:
Causes a generic and its subunits to be gathered into one file when the generic is downloaded. Computation of recompilation order will take the repackaging into account.
Must be implemented in customization scripts.- Implements_Pragma_Inline:
Introduces recompilation dependencies between the body of an inlined process and its callers. (Such dependencies will be ignored if they introduce circularities, under the assumption that normal calls will be generated if the body has not been installed.)
- Separate_Subunits_Are_Inefficient:
Causes separate subunits to be pulled inline when the unit is downloaded to the target.
Causes compiler to call customization script rci_group_compile during compilation of a generic spec.- Specs_Can_Be_Coded:
Permits unit specs to be coded on target (otherwise if a spec is coded, it will automatically succeed without invoking the target compiler, provided that it successfully analyzes).
Must be implemented in customization scripts (for example. by trapping calls that code specs in rci_runon).- Generics_Can_Be_Coded:
Permits generic specs and bodies to be coded on target (otherwise if a generic unit is coded, it will automatically succeed without invoking the target compiler, provided that it successfully analyzes).
Must be implemented in customization scripts (e.g. by trapping calls to code generic units in rci_runon).- Compilation_Mode:
can have the value INTERACTIVE or BATCH. If mode is interactive, target compilation will occur one unit at a time. If mode is batch, target compilation commands will be written to the batch script file.
Compilation_Mode is a required compilation rule.Fill in the production for compilation_rules as shown in Figure 15, then take a look at the completed examples in the rci_op.spec file included in the VADS and GNAT example customizations.
Example Compilation Rules Specification
Figure 16 shows the compilation rules specification for the VADS example customization.
Figure 16 Example Compilation Rules Specification
( COMPILATION_RULES IMPLEMENTS_PRAGMA_INLINE SPECS_CAN_BE_CODED GENERICS_CAN_BE_CODED COMPILATION_MODE "INTERACTIVE" )
Defining Target Command PropertiesThis section describes how to specify command properties for your target compilation platform. The command properties are included in the file rci_op.spec in your compiler key.
The production for command properties is shown in Figure 17.
Figure 17 Command Properties Specification
( COMMAND_PROPS COMMAND_LINE_CASE < UPPER | LOWER > MAX_COMMAND_LINE_LENGTH #integer# CONTEXT_COMMAND #string# CODE_COMMAND #string# LINK_COMMAND #string# LINK_UNIT_SPECIFICATION_KIND < ADA_NAME | FILE_NAME > EXECUTABLE_OPTION_UNIT_SPECIFICATION_KIND < ADA_NAME | FILE_NAME > SPEC_FILENAME_EXTENSION #string# BODY_FILENAME_EXTENSION #string# EXTENSION_SEPARATOR #string# ADA_NAME_SUBUNIT_SEPARATOR #string# ADA_NAME_SPEC_SUFFIX #string# ADA_NAME_BODY_SUFFIX #string# COMMAND_ARG_SEPARATOR #string# INTER_COMMAND_SEPARATOR #string# [CASE_SENSITIVE] [ADA_NAME_IS_LOWERCASE] [HOST_NAME_EQUALS_TARGET_NAME] [GENERATE_BATCH_COMPILE_COMMANDS])The definitions of individual Command Properties are shown in Table 2.
Example Command Properties Specification
Figure 18 shows the command properties specification for the VADS example customization.
Figure 18 Example Command Properties Specification
( COMMAND_PROPS COMMAND_LINE_CASE "LOWER" MAX_COMMAND_LINE_LENGTH 255 CONTEXT_COMMAND "cd" CODE_COMMAND "ada" LINK_COMMAND "a.ld" LINK_UNIT_SPECIFICATION_KIND "ADA_NAME" EXECUTABLE_OPTION_UNIT_SPECIFICATION_KIND "ADA_NAME" SPEC_FILENAME_EXTENSION "a" BODY_FILENAME_EXTENSION "a" EXTENSION_SEPARATOR "." ADA_NAME_SUBUNIT_SEPARATOR "__" ADA_NAME_SPEC_SUFFIX "_" ADA_NAME_BODY_SUFFIX "" COMMAND_ARG_SEPARATOR " " INTER_COMMAND_SEPARATOR ";" CASE_SENSITIVE ADA_NAME_IS_LOWERCASE )
Defining Target Compiler and Linker OptionsApex/RCI invokes the target compiler and linker with options specified in the comp_option and link_option files in the host view on a per-compilation-unit basis. All options that appear in these files must have been declared in the RCI customization. The compiler vendor defines the compiler options, but you, the customizer, decide which options and what names to use for the identifiers that map to those options. The declaration of compiler and linker options forms a part of the operational characteristics specification, so it is found in the file rci_op.spec in the compiler key.
The Apex Ada compiler requires some additional files in your compiler key directory, which it uses to parse the comp_option and link_option files. The files are:
- comp_option_line
- comp_option_symbol
- link_option_line
- link_option_symbol
Once your options are declared in rci_op.spec, you can generate the files above with the check_rci_specification command in an Apex shell:
% apex check_rci_specification \ -directory <new_compiler_key
>Note: You can customize these options now for the basic customization, or this can be done later in the customization process. Either way, you need to run check_rci_specification to generate the four files listed above in the compiler key before your customization is ready for use (unless you are using options declarations from an existing customization, in which case you can copy the options files from that customization into your compiler key).
What Information to Gather
Use the target compiler reference manual to obtain a list of valid compiler command line options. For each option, you need:
- The option name
The text that will be inserted into the command line for the option; for example, v as the text for the -v (verbose) option.
- The switch name
The name used to identify the option in the comp (or link)_option_symbol file in the compiler key directory. The name should describe the compiler option, for example, verbose to create the <verbose> identifier in the file.
- The list of compilation phases where the option is legal.
The values must be 0 or more of the following:
- Code
- Link
- Any arguments that the option permits
- Whether the option should be on by default (only applies for options which do not take arguments; i.e. switches). Such options will not appear in the comp_option_file or default_option_file default line, but will appear in each target command.
Specification for Compiler Options
Figure 19 shows the specification for compiler options.
Figure 19 Compiler Options Specification
( COMPILER_OPTIONS OPTION_SEPARATOR #string# OPTION_HEADER #string# OPTION_ARGUMENT_SEPARATOR #string# EXECUTABLE_OPTION #string# [EXECUTABLE_OPTION_IS_PRE_OPTION] { ( OPTION ... ) } )The definitions for the components of Compiler Options are shown in Table 3, and the full specification of Option is shown in Figure 20 and defined in Table 4.
The Specification for Option is shown in Figure 20.
Figure 20 Option Specification
( OPTION #id# ACTIVE_PHASES [CODE] [LINK] SWITCH_NAME #string# [ALWAYS_APPLIED] [OPTION_TAKES_ARG] [IS_PRE_OPTION] )The definitions for the components of an Option specification are shown in Table 4:
Example Compiler Options Specification
Figure 21 shows the Compiler_Options included in the VADS example customization (only a few of the options are included in this example). See rci_op.spec in the VADS customization compiler key view.
Figure 21 Example Compiler Options Specification
( COMPILER_OPTIONS OPTION_SEPARATOR " " OPTION_HEADER "-" OPTION_ARGUMENT_SEPARATOR "" EXECUTABLE_OPTION "o" EXECUTABLE_OPTION_IS_PRE_OPTION ( OPTION "A" ACTIVE_PHASES CODE SWITCH_NAME "A" OPTION_TAKES_ARG IS_PRE_OPTION ) ( OPTION "a " ACTIVE_PHASES CODE SWITCH_NAME "a" OPTION_TAKES_ARG IS_PRE_OPTION ) ( OPTION "c" ACTIVE_PHASES CODE SWITCH_NAME "c" IS_PRE_OPTION ) ( OPTION "D " ACTIVE_PHASES CODE SWITCH_NAME "D" OPTION_TAKES_ARG IS_PRE_OPTION ) ( OPTION "d" ACTIVE_PHASES CODE SWITCH_NAME "d" IS_PRE_OPTION ) )Updating Compiler and Linker Options
After you change options in an existing customization, you must rerun the check_rci_specification command to update the new options in the compiler and link options files in your compiler key directory.
Users can specify options on a unit by unit basis by modifying the comp_option_file or link_option_file in their views. See the RCI User's Guide for more information.
You can define option defaults by placing those values in the comp_option_file and link_option_file files in the model view for the customization. Existing views do not automatically inherit the new model, so users must remodel their existing views to get the default values.
Defining Target Operational DataThe Last Component to be defined in Operational Characteristics is Operational Data, consisting mostly of information about the target OS and filesystem characteristics.
The Specification for Operational Data is shown in Figure 22.
Figure 22 Operational Data Specification
( OPERATIONAL_DATA MAX_FILENAME_LENGTH #integer# FULL_PATHNAME_LENGTH #integer# DIRECTORY_SEPARATOR #string# DIRECTORY_PREFIX #string# DIRECTORY_SUFFIX #string# DIRECTORY_UNIT_SEPARATOR #string# CONNECTION_KIND #string# [USE_DEFAULT_DOWNLOADING] )The Operational Data components are defined in Table 5:
Table 5 Operational Data
Parameter Type Value
MAX_FILENAME_LENGTH Natural Maximum filename length for the remote operating system and compiler.
FULL_PATHNAME_LENGTH Natural Maximum pathname length for the remote operating system.
DIRECTORY_SEPARATOR String A fully qualified filename would be of the following format:
<DPREF>dir_name1<DS>dir_name2<DS>dir_ name2<DS>....
<DS>dir_name_n<DSUF><DUS>unit_name
Where
<DS> => directory_separator,
<DPREF> => directory_prefix,
<DSUF> => directory_suffix,
<DUS> =>
directory_unit_separator.
For example, for the VMS file, [EXP.TESTS.SUB]file,
<DS> -> ".",
<DPREF> -> "[",
<DSUF> -> "]",
<DUS> -> ""
DIRECTORY_PREFIX String
DIRECTORY_SUFFIX String
DIRECTORY_UNIT_SEPARATOR String
USE_DEFAULT_DOWNLOADING Optional switch If Included, RCI chooses how to download files. If omitted, RCI downloads by calling the script rci_post_put in your compiler key directory.
CONNECTION_KIND String The kind of connection. Valid kinds are nfs_rsh, nfs_rcp.
Example Operational Data Specification
Figure 23 shows the Operational Data included in the VADS example customization.
Figure 23 Example Operational Data Specification
( OPERATIONAL_DATA MAX_FILENAME_LENGTH 255 FULL_PATHNAME_LENGTH 800 DIRECTORY_SEPARATOR "/" DIRECTORY_PREFIX "" DIRECTORY_SUFFIX "" DIRECTORY_UNIT_SEPARATOR "/" CONNECTION_KIND "nfs_rsh" USE_DEFAULT_DOWNLOADING )Testing the Operational Characteristics Specification
Once your specification for Operational Characteristics is complete, you can perform two levels of testing. To test the syntax of your specification, in an Apex shell run the following command:
% apex check_rci_specification \ -directory <compiler_key> \ -rci_prevent_buildYou can perform a series of tests to check the correctness of your customization now, by creating host-target RCI views and attempting to code and link on target. You may find it helpful to set the rci_runon script to verbose, in order to better inspect the parameters it is being passed, and which it is in turn using to build the target command.
Once you have the basic commands working correctly, try setting various combinations of target options in the link_options_file and comp_options_file in your test view, both in the default line and on a file by file basis.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |