![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Compiling and Executing Compiling and Executing can be done a number of ways in Apex This chapter covers the commands in the Compile menu and describes how to create a configuration file.
About this Chapter
The chapter contains the following topics:
- The Apex Compilation Model (Ada only)
- Compiling a Program
- Linking a Program
- Creating C/C++ Executables Linked with Ada Subroutines
- Creating C/C++ Main Programs with Ada Subroutines
- Including C/C++ Code in an Ada Program (Ada only)
- Placement of Executables in a System Configuration
- System Builds Against Varying Source Bases
- Configuration Files (Apex/Summit)
- Distributed Compilation and Execution
The Apex Compilation Model (Ada only)Every compilation command produces permanent information that is used by succeeding commands. For example, the Compile > Analyze command produces semantic information and stores it in a DIANA tree (an intermediate structure created and used internally by the compiler). The Compile > Code command uses this information to produce object code. (If a succeeding command does not find the information it needs —— for example, because you skipped a compilation step —— the preceding compilation commands are invoked automatically.) During the various stages of compilation, every program unit is always in one of the compilation states described in Table 16.
Table 16 Apex Compilation States
State Description
Archived The current unit contains no compiler-related information. Either the unit has never been processed by the compiler or all compiler information has been removed. For Ada only.
Source The current unit has been parsed. The Compile > Parse and Compile > Syntax commands advance a unit to this state. For Ada only.
Installed The current unit has been checked for semantic consistency. When an Ada unit is being compiled, semantic analysis checks whether the unit is a legal Ada compilation unit. The Compile > Analyze command advances the unit to this state. For Ada only.
Coded Object code has been generated for the unit. The Compile > Code command advances the unit to this state. For Ada only.
Unparsed The source file has been updated since the compiler was last run.
Some commands that are not on the Compile menu recognize the compilation states listed above. For example, in Apex/Summit, when you execute the File > Copy command to copy a Summit/CM view, you are asked to specify a goal state. This goal state determines the level of compilation that applies to the new view you create.
Additional information on Ada compilation can be found in the Ada Compiler Reference.
Closure Sets
A program unit can be processed to a particular compilation state only if a set of other units has also been processed to that state. For example, an Ada unit can be analyzed only if all of its withed units have also been analyzed. Therefore, a unit and a compilation state are sufficient to define a set of other units that is known as the compilation-state closure set.
The different closure sets are described in Table 17.
Optimal Recompilation
When Apex recompiles units that have been modified, the compiler performs optimal recompilation. Optimal recompilation combines incremental semantics with fast-path recoding.
When incremental semantics are performed, the compiler:
- Ignores all white space and comment changes
- Avoids analysis when semantic changes in lower-level units are detected to be upward-compatible
- Performs incremental analysis at the statement level for all units affected by semantic changes that are not upward-compatible
- Performs full analysis for units not previously analyzed
When fast-path recoding is performed, the compiler:
- Avoids coding units that did not need to be reanalyzed
- Regenerates all object code for reanalyzed units —— even after incremental analysis —— to allow full compiler optimization
Compiling a ProgramCompilation can be done in any Summit/CM views (Apex/Summit) that are not frozen or in any Rational subsystem (Apex/ClearCase). The following can be compiled using the Compile > Code command:
- Individual units or files. Sometimes an individual unit or file is compiled directly from the editor. This is useful if you have made a change and want to see if it compiles without errors. To compile an individual unit and file from an editor window, choose Compile > Code. To compile an individual unit or file from a directory-viewer window, select the file and choose Compile > Code.
- All the units and files in a view or directory and any units and files that they reference that require compiling. You might do this after making a number of changes in a view and wanting all the units and files to be compiled. To compile all the units and files in a Summit/CM view or subdirectory of a Summit/CM view (Apex/Summit) or a Rational subsystem (Apex/ClearCase), choose Compile > Code. In the resulting Code dialog box, add the name of the view, subdirectory or Rational subsystem to the Code list and then click OK or Apply.
- All the existing units and files needed to link a program. To compile all the exisitng units or files needed to link a program, select:
Choose Compile > Code and in the resulting Code dialog box, click the Existing units in linkage closure button and click OK or Apply to run the compilation.
- Ada: the unit that is the root of the program (a parameterless procedure, which will be executed as the entry point of the program after elaboration)
- C++: the main function.
In Apex, a program is always compiled within the compilation context of its enclosing Summit/CM views or Rational subsystems. The compilation context of a Summit/CM view or Rational subsystem encompasses the compiler that is used, the values of the compiler's switches, and any imported Summit/CM views or Rational subsystems that provide external visibility to the units being compiled.
The language editor window`s Compile menu offers a selection of commands for semanticizing, parsing, pretty-printing, compiling and linking language code in the compilation context of their enclosing Summit/CM views or Rational subsystems. Note that the selection of commands available is dependent on whether the Ada or C++ editor is being used.
For C/C++, additional information on compilation can be found in the C++ Compiler Reference.
Compile Menu Commands
The compilation commands available from the Compile menu are described in Table 18.
Linking a ProgramApex linking is done with the Compile > Link command.
For Ada Programs
Any parameterless procedure can serve as the root of an Ada program that can be linked to produce an executable. There are some special pragmas that can be applied to units that are to be linked to produce executables, specifically pragma Main. One thing the presence of pragma Main does is to mark the unit explicitly as a main procedure that is to be linked.
If main procedures contain a pragma Main (usually in the body), then a Summit/CM view or subdirectory or a Rational subsystem can be specified in a Compile > Link command and all contained procedures that have pragma Main will be linked as a result.
Pragma Main is discussed in detail in the Ada Compiler Reference, available online through the Help > Manuals command.
Note: (Tornado Only) Tornado is a multitasking environment with a single memory map shared across all loaded applications. Any C function can be spawned as a task.
For C/C++ Programs
The main function of a C/C++ program must be named main().
If you did not create the main using the File > New > New C++ or the File > New > New C command with the main option, you will need to register each main() function using the Compile > Maintenance > Register Main Program command.
If you did not use Apex to create your files, you will need a makefile. Please see the online Command Reference for information on creating and using a makefile.
For Ada Interfacing to C/C++ Programs (Duo only)
In the Ada view containing the Ada main program, you need to run the Compile > Maintenance > Enable C++ Linking command to set the appropriate switches. You also need to either import the C/C++ views or use a configuration file listing all the C/C++ views. More information on this process is found in Including C/C++ Code in an Ada Program (Ada only).
Each C/C++ function is accessed from the Ada code using the Interface pragma. Please see the Ada Compiler Reference and the C/C++ Compiler Reference for more information.
Error Checking (C/C++)
When you write C/C++ source code using the Apex C/C++ editor, you can check your C/C++ files for errors as you edit them. The Compile > Code menu command performs error checking.
When you execute the Code command, Apex displays any errors found in the Output window and in a Summary window. You can traverse from an error in the Summary window by double-clicking on the error message. In addition, you can select an error in the C/C++ editor that is highlighted and execute the Help > Explain command to display the corresponding error message.
Creating C/C++ Executables Linked with Ada SubroutinesFollow these steps to create a C/C++ executable that is linked with Ada subroutines:
- 1 . A C/C++ view with a main program. Some portion of that program must declare the Ada subroutine(s) as extern "C" subroutines. Something like this:
extern "C" { void A_Procedure; // For an Ada procedure with no arguments int A_Function (int X); // For an Ada function with one argument };
- 2 . An Ada view with a main program that WITH's all of the Ada units that contain exported Ada routines that will be called from the C/C++ main.
The C/C++ view can import other C/C++ views and any or all of those views can make calls to the Ada subroutines. Note that only the view containing the main program requires special attention.
The Ada view can import other Ada views and any or all of those views can export routines for the use of the C/C++ main program. But is it only the view containing the Ada main program that requires special attention.
Creating C/C++ Main Programs with Ada SubroutinesFollow these steps to create a C/C++ main program with Ada subroutines:
- 1 . Create an Ada 83 or Ada 95 subsystem and a view in that subsystem. This view is the "Ada view" referenced below.
An alternative is to use an existing Ada 83 or Ada 95 subsystem and view.
- 2 . If they do not already exist, create some Ada units that export C interfaces to some of their routines. Those units may exist in the Ada view or they may exist in any view imported by the Ada view.
- 3 . In the Ada view, create an Ada main program that WITHs every unit that contains an exported C interface that will be called by the C/C++ main program. A suitable main program would be a procedure, taking no parameter, and having a "null;" body block.
add a "pragma Pseudo_Main;" as the last line of the main program. It comes after the "end Xxxx;". It is a library unit pragma (RM 10.1.5(7)).
The body of the Ada main program will never be executed. It is used solely to cause elaboration, and eventually finalization, of the Ada portion of the C/C++ program.
- 4 . Link the Ada main program. If the name of the main program is main.2.ada, this will create a file named main.cpp_callables.
- 5 . Create a C/C++ subsystem and a view in that subsystem. This view is the "C++ view" discussed below.
An alternative is to use an existing C/C++ subsystem and view. If the existing view is already used to create executable C/C++ main programs, and if those programs should not be linked with the Ada subroutines then it is not a good idea to reuse that view for this purpose. The reason is that the C_LINK_OPTIONS/CPP_LINK_OPTIONS switch setting will cause those main programs to link in the unnecessary Ada subroutines. The switch can be changed every time the immediate need changes but that is inconvenient. It will be more convenient to create a new subsystem and view.
- 6 . Create a C/C++ main program that calls the Ada subroutines.
The C/C++ main program must call the Ada runtimes "adaint" subroutine before it calls any other Ada subroutine. This elaborates the Ada portion of the program. The main program should call the "adafinal" subroutine before it exits. This will finalize the Ada portion of the program.
- 7 . Run the enable_ada_linking command in the C/C++ view.
enable_ada_linking \ -cpp_callables <Ada view>/<main>.cpp_callables \ -model <Ada model used> \ <C/C++ view>
This modifies the C/C++ view. It sets some necessary switches in the view's switches file and it creates a file named Ada_Imports.cfg in the view. The debugger uses the Ada_Imports.cfg file to locate the source code for the Ada subroutines. The Ada model information is used so that the correct compiler support can be incorporated. This should match the model used by the Ada view.
- 8 . In the C/C++ view, modify the C_LINK_OPTIONS (for a C main) or the CPP_LINK_OPTIONS (for a C++ main) switch to include the full path of the .cpp_callables file produced by linking the Ada main program.
The enable_ada_linking script doesn't do this because the C/CPP_LINK_OPTIONS which may contain any arbitrary amount of information and the ordering of the items withing that information can be very important.
- 9 . Perform an "apex build" operation on the C/C++ view.
- 10 . Link the C/C++ main program.
- 1 . Create an Ada 83 or Ada 95 subsystem and a view in that subsystem.
This view is the "Ada view" discussed below.
apex create_subsystem ~/ada.ss apex create_working -model $APEX_ADA95_MODEL ~/ada.ss/view.wrk
- 2 . If they do not already exist, create Ada units that export C interfaces to some of their routines. Those units may exist in the Ada view or they may exist in any view that is imported by the Ada view.
package Unit_One is procedure C_One; pragma Export (Convention => C, Entity => C_One, External_Name => "C_One"); end Unit_One; ------------------------------------------------------- with Text_Io; package body Unit_One is procedure C_One is begin Text_Io.Put_Line ("C_One"); end C_One; end Unit_One; ------------------------------------------------------- package Unit_Two is procedure C_Two; pragma Export (Convention => C, Entity => C_Two, External_Name => "C_Two"); procedure C_Three; pragma Export (Convention => C, Entity => C_Three, External_Name => "C_Three"); end Unit_Two; ------------------------------------------------------- with Text_Io; package body Unit_Two is procedure C_Two is begin Text_Io.Put_Line ("C_Two"); end C_Two; procedure C_Three is begin Text_Io.Put_Line ("C_Three"); end C_Three; end Unit_Two;
- 3 . In the Ada view, create an Ada main program that WITHs every unit containing an exported C interface that will be called by the C/C++ main program. A suitable main program would be a procedure, taking no parameter, and having a "null;" body block.
add a "pragma Pseudo_Main;" as the last line of the main program. It comes after the "end Xxxx;". It is a library unit pragma (RM 10.1.5(7)).
with Unit_One; with Unit_Two; procedure Fake_Main is begin null; end Fake_Main; pragma Pseudo_Main;
- 4 . Link the Ada main program. If the name of the main program is main.2.ada, this will create a file named main.cpp_callables.
apex link ~/ada.ss/view.wrk/fake_main.2.ada
- 5 . Create a C/C++ subsystem and a view in that subsystem. This view is the "C++ view" referenced below.
apex create_subsystem ~/cpp.ss apex create_working -model $APEX_CPP_MODEL ~/cpp.ss/view.wrk
- 6 . Create a C/C++ main program that calls the Ada subroutines.
#include <iostream.h> extern "C" { int adainit (int argc, char **argv); void adafinal (); void C_One (); void C_Two (); void C_Three (); } int main (int argc, char **argv) { cout << "Starting...\n"; cout.flush (); adainit (argc, argv); C_One (); cout << "Finishing...\n"; cout.flush (); C_Two (); C_Three (); adafinal (); cout << "Done.\n"; cout.flush (); }
- 7 . Run the enable_ada_linking command in the C/C++ view.
enable_ada_linking \ -cpp_callables ~/ada.ss/view.wrk/fake_main.cpp_callables \ ~/cpp.ss/view.wrk
- 8 . In the C/C++ view, modify the C_LINK_OPTIONS (for a C main) or the CPP_LINK_OPTIONS (for a C++ main) switch to include the full path of the .cpp_callables file produced by linking the Ada main program.
apex set_switch -switch_context ~/cpp.ss/view.wrk \ CPP_LINK_OPTIONS ~/ada.ss/view.wrk/fake_main.cpp_callables
- 9 . Perform an "apex build" operation on the C/C++ view.
apex build ~/cpp.ss/view.wrk
- 10 . Link the C/C++ main program.
apex link ~/cpp.ss/view.wrk/main.C
Including C/C++ Code in an Ada Program (Ada only)In Apex, there are two methods of including C/C++ code in an Ada program. The first, described here, is the preferred way of created mixed language executable programs. The second method, described in the Ada Compiler Reference, is useful for C/C++ code not held in Summit/CM views or Rational subsystems.
Warning: Regardless of the method used, C++ code compiled with a C++ compiler other than Apex C++ should be considered C code. Static constructors and destructors of such C++ code is not automatically called on most target operating systems.
Method 1: Code Compiled/Stored in Apex C/C++ Views/Rational Subsystems
Linking with C/C++ code in Summit/CM views or Rational subsystems required a linker configuration file or importing of the C/C++ views into the Ada main view or Rational subsystem. In addition, the Ada main Summit/CM view/Rational subsystem, needs to be set up for linking with C/C++ code using the command Compile > Maintenance > Enable C++ Linking.
The following steps outline a simple process for including C/C++ code in an Ada program:
- 1 . Create a Summit/CM view in the subsystem or a Rational subsystem that will contain the C or C++ code. Use a C++ model.
- 2 . If using C, add any desired C options to the C_OPTIONS
switch. If using C++, add any desired C++ options to the CPP_OPTIONS switch. For example, -I/usr/motif/include.- 3 . In an Ada Summit/CM viewor Rational subsystem, build your "bindings" or interface specifications.
- 4 . Import the C++ view/Rational subsystem into the Ada view/Rational subsystem where the "bindings" reside. In Apex/Summit, note that you could also do this with a linker configuration file. Note that if you use the linker configuration file, the C/C++ views listed in this file cannot contain the C++ view of the same subsystem or Rational subsystem where the main Ada program is being linked.
- 5 . In the Ada view/Rational subsystem in which you will link, execute the Compile > Maintain > Enable C++ Linking, supplying the model of the C++ Summit/CM view/Rational subsystem in the Enable C++ Linking dialog box.
- 6 . Link your program.
Method 2: C/C++ Code Not Compiled with Apex C++
This method is more convenient for including pre-packaged libraries or object files for which the user does not have the source. The C/C++ code is usually available as a set of .a or .o files not in a Summit/CM view or Rational subsystem. Using this method, no configuration files or imports are required. The .a and .o files which need to participate in the link are specified using either the NON_ADA_LINKAGE switch or using pragma Linker_Options. Note that the pragma and the switch can be used in combination or there can be several instances of pragma Linker_Options. However, the same .a or .o file cannot appear more than once.
This method is described in greater detail in the Ada Compiler Reference.
Placement of Executables in a System ConfigurationAda Parameterless procedures and C/C++ main functions that are to be linked to produce executables can be placed in any subsystem that has sufficient imports to compile them. Often, small test procedures are scattered throughout a system configuration and these test procedures can be linked to execute parts of a system.
It is often advantageous to place the main executables that will be the delivered programs from a system in their own subsystem. This means that there is a subsystem, in the avionics example (introduced in Description of Example) called executables in the control directory, where the parameterless procedures that the mains are located. Linking, execution, and debugging are done from Summit/CM views of this subsystem (Apex/Summit) or the Rational subsystem itself (Apex/ClearCase). The reasons for doing this are:
- Developers may have their own copy of only a few subsystems, but will always need a place to link and execute the system. If executables are distributed among various subsystems, all developers would need their own view of each subsystem that has an executable.
- Executables are often large and separating them from the bulk of the source and object files makes it easier to manage the disk space involved. Views of the subsystem containing the executables can be placed on different UNIX file systems.
- There is often the need to keep executables even if the source changes and are not explicitly kept. Having a separate subsystem for executables allows keeping all the required executables without having to keep any significant amount of the source code.
- When doing system builds or recombinant testing, you often link against a variety of different Summit/CM views or Rational subsystems. Separating the executables from the bulk of the source makes this easier.
System Builds Against Varying Source BasesNormally, when a program is created during a Compile > Link operation, the object files that participate in the link are those from the Summit/CM views or Rational subsystems containing the main unit(s) or file(s) and from the imported Summit/CM views/Rational subsystems.
Thus, the source that is compiled as part of compiling the closure of the main unit(s) or file(s) corresponds to code that ends up in the executable(s). While this is normally what is desired, there are tasks in working with large systems where this is not the case. For example:
- When a developer is changing a single subsystem and the change is compatible with another system configuration, the developer probably would like to link the new subsystem with the subsystems of the other system configuration even though that system configuration is not compiled against the new subsystem.
- When regression tests are being run, results from builds of the system with some different sets of subsystems may be needed for comparisons.
- When system integration is being done, a build may want to connect parts of the system with compatible interfaces that were not necessarily compiled directly against each other.
Apex offers the ability to link executables by combining object files from Summit/CM views or Rational subsystems other than those that were compiled against each other. An object called a configuration file is used to specify the specific views of each subsystem (Apex/Summit) or Rational subsystems (Apex/ClearCase) that is to supply object files to the link. The Apex compilation systems assure that, when executables are linked using such configurations, interfaces from the different Summit/CM views/Rational subsystems are compatible. For more information, please see Configuration Files (Apex/Summit).
Apex/Summit
An example is illustrated in Figure 18 using the base.3.rel system configuration of the avionics system. A developer Jones is building a new version of the radio_packet.ss subsystem in view jones.wrk. Jones now wants to test the new version that is spec-compatible (for example, the Ada package specifications and C/C++ function prototypes have not changed) with the current version in the base.3.rel system configuration Jones has two views: one for the new radio packet code and one in which to build the executable to try. What Jones needs to do is to link the executable. Rather than specifying that the object files from the imported views be used, he must specify that object files from radio_packet.ss/jones.wrk and the base.3.rel views of all of the other subsystems be used in the link.
Figure 18 Linking Executables (Apex/Summit)
![]()
To do this, a configuration file must be created that lists exactly these views. Then the Compile > Link operation is performed specifying that configuration in the Link with configuration field.
Configuration Files (Apex/Summit)A configuration is a text file that provides a way to group together views from different subsystems. For example, to construct a system release, you can create a configuration that includes release views from each of the system's component subsystems.
The contents of a configuration are either the fully qualified names of views or the fully qualified names of other configurations. Configurations are also used to specify the closure when main programs are to be linked.
The following are important points to remember when dealing with configuration files:
- When using configurations, the import structure must still exist
- The configuration file needs to reference only those views that differ from those imported, and not the whole closure
- Views referenced in the configuration file must be compatible with the views referenced from the import structure; that is, the same set of units and the same interfaces for anything that is relevant to compilation.
Creating a Configuration
A configuration file is a normal text file with a .cfg suffix containing a list of views or other configurations. When a configuration file names another configuration file it is as though the contents of the referenced configuration file were placed at the point of reference. Blanks and comment lines are also allowed. Comment lines begin with the character "#".
Configuration files can be created in a number of ways:
Method 1: To create a configuration file using Apex with the intent of typing or pasting the contents, follow these steps:
- 1 . From an Apex window, choose File > New > New Configuration.
- 2 . In the resulting New Configuration dialog box, enter the configuration and context.
If you want the configuration to be placed under Summit/CM control, check the Make it controlled check box.
- 3 . Click OK or Apply to create the new configuration.
Then, or later, you can edit the configuration as a normal text file.
Method 2: You can also create a configuration file with specific contents. Here are two examples.
Suppose you wish to create a configuration listing all of the rev.1.wrk system configuration of the avionics system. To do this, run the following UNIX command from a shell:
ls -1d /projects/avionics/*/*.ss/rev.1.wrk> all_views.cfg
This creates a file that lists exactly the currently existing views in the rev.1.wrk system configuration. The file will be called all_views.cfg.
Method 3: Suppose you wish to create a configuration that lists exactly the views in the import closure of a view, rev.1.wrk. That is, the configuration is to list all of the views directly imported by rev.1.wrk, and all the views that the direct imports import, and so on. To do this, follow these steps. (In this example you will build a configuration called full_imports.cfg that contains the import closure of the view /projects/avionics/control/executables.ss/rev.1.wrk.)
- 1 . To create a configuration file, choose File > New > New Configuration in a directory-viewer window on the executables.ss/rev.1.wrk view.
- 2 . In the resulting New Configuration dialog box, enter the name full_imports.cfg in the Name field.
- 3 . Click OK to create the configuration.
- 4 . To create an Imports viewer window, choose Control > Show > Imports from the same directory-viewer window.
This Imports viewer window lists all the views in the direct and closure imports.
- 5 . In the Imports viewer window, select all of the views and then choose Edit > Copy Selected Names.
This places the fill names of all the views on the clipboard.
- 6 . In the editor window for the full_imports.cfg configuration choose Edit > Paste.
- 7 . To save the window by clicking on File > Save.
Example of a Configuration File "all_views.cfg"
# Configuration File for the Avionics project /projects/avionics/passenger_cabin/passenger_seat_console.ss/rev.1.wrk /projects/avionics/passenger_cabin/video_library.ss/rev.1.wrk /projects/avionics/passenger_cabin/airphone.ss/rev.1.wrk /projects/avionics/passenger_cabin/lighting.ss/rev.1.wrk /projects/avionics/flight_control/engines.ss/rev.1.wrk /projects/avionics/flight_control/wings.ss/rev.1.wrk /projects/avionics/flight_control/fluel_management.ss/rev.1.wrk /projects/avionics/flight_control/hydrolics.ss/rev.1.wrk /projects/avionics/flight_control/rudder.ss/rev.1.wrk /projects/avionics/ip_communication/fault_monitor.ss/rev.1.wrk /projects/avionics/ip_communication/packet_routing.ss/rev.1.wrk /projects/avionics/ip_communication/net_drivers1.ss/rev.1.wrk /projects/avionics/ip_communication/net_drivers2.ss/rev.1.wrk /projects/avionics/ground_communications/communications.cfg /projects/avionics/cockpit/cockpit.cfg /projects/avionics/os_interface/os_interfaces.cfg /projects/avionics/navigation/navigation.cfgLinking With a Configuration
Normally when a program is linked, the import closure is used to determine all the units (and hence .o files) that will be included in the link. It is possible to use a configuration file instead to determine what files other than those in the view containing the unit being linked will be included.
This is done to support recombinant testing or other scenarios when programs may be constructed from compatible, but different, source bases.
To link with a configuration, first create the configuration file. Then execute the Compile > Link command and place the configuration name in the Link with the configuration field. When OK or Apply is pressed, the link will use the stated configuration rather than using imports. If there is a context switch CONFIGURATION set to a nonnull value in the switch file in the view, it will be used as the default. If no configuration is specified in the dialog box, the value of the CONFIGURATION switch will be used as a configuration. You set this switch if it is always or almost always the case that a particular configuration will be used in the link.
For the example above, create a configuration called test_radio_packet.cfg and set it to the set of imported views as was done in the previous section.
Then, edit it to replace radio_packet.ss/rev.1.wrk with radio_packet.ss/jones.wrk. When running the link, fill in the configuration name. Place the name of the executables.ss/jones.wrk view in the Units to link field as illustrated in Figure 19. This will result in all main objects in the view being linked with the radio_packet.ss/jones.wrk view and rev.1.wrk views for all other imported avionics subsystems.
Figure 19 Link Dialog Box
![]()
Distributed Compilation and ExecutionApex allows you to run code commands in parallel over the network. The correct architectures are selected based on the BUILD_KEY switch. This facility works by forking a command server on a remote machine of the appropriate architecture.
The facility also supports multi-machine usage by executing the debugger, link and run commands on the appropriate machine based on the model.
To use this distributed facility, you need to define the names of the machines and their types of architectures on the network via an Execution Specification File. Distributed compilation is performed by selecting the code in parallel when possible button in the Code dialog box. Additionally, regardless of the machine running the Apex session, every Compile > Code command will execute on a machine architecture that matches the view's architecture.
Systems Requirements for Distributed Compilation and Execution
The distributed compilation and execution facility has the following requirements:
- The network must run NFS.
- The machines must be accessible over NFS.
- The user's login must work correctly for execution of Apex
- The on and rsh commands must function over the network.
- The execution file must be visible on the remote hosts.
- The Apex temporary directory, ususally $HOME/.Rational/tmp, must be visible on the remote hosts. This can be accomplished by setting APEX_TEMP_DIR to a directory which is visible on both the local and remote machines.
Execution Specification File
An execution specification file specifies machines and their architectures on the network to use for distributed compilation and/or execution. It also specifies which Apex commands should be distributed. The name of the file must be "execution".
To use the distributed compilation for a particular user, place the file in the user's $HOME/.Rational directory. For site-wide distributed compilation, place the execution file in the editor_files subdirectory of the directory specified by the product's local_dir.
Sample site-wide configuration setup
- 1 . Create a file local_dir in the config directory for the product (rational_dir/config)
- 2 . Edit the local_dir file to contain exactly one line, which is the full path to a shared (visible by all users) directory, an example of the contents might be: /rational/shared_local.
- 3 . Create the editor_files subdirectory (mkdir /rational/shared_local/editor_files)
- 4 . Place the execution file in the editor_files directory.
execution file format
The execution file has the following basic format:
#// global information section (defaults) method:method
#// The following commands/machines lines can be omitted, #// if commands are listed for each architecture commands: net code link machines:machine_1 machine_2 machine_3
#// architecture specific information section arch:machine_arch
method:method
commands:net link
machines:machine_1 machine_2
cross:machine_y machine_z
arch:machine_arch
method:method
cross:machine_a machine_b
arch:machine_arch
machines:machine_4 machine_3
cross:machine_c machine_d
....where:
commands: is a blank sparated list of Apex commands that may be distributed.
machines: is a blank separated list of machines on which to do the distributed commands.
arch: is a supported Apex architecture for the installed release of Apex. For example, in Apex 4.2 machine_arch supported architectures include i386_linux2, sun4_solaris2, rs6k_aix, alpha_osf1, hppa_hpux, and mips_irix5.
method specifies the command used to communicate with another machine. The typical method is either on or rsh. The default is on. Machines that do not have the UNIX on command need to indicate a method.
machine_N, is the name of a machine that corresponds to the proceeding architecture. These lines specify which machines may execute architecture-dependent commands. A machine is selected based on where it is listed and the position in which it occurs; the machines specified in the machines list take presedence over those in the cross list.
Example of Execution Specification File
#// global information section (defaults) method: on commands: net code machines: pluto twain kong pleiades mercury ra venus #// architecture specific information section arch: i386_linux2 method: ssh commands: net code link machines: geyser flow lava cross: mica arch: sun4_solaris2 cross: mercury mercury arch: rs6k_aix commands: net link machines: brust chisel cross: vega gambelia mayce arch: alpha_osf1 method: rsh cross: ra venus velvet arch: hppa_hpux machines: pluto twain kong cross: lal arch: mips_irix5 cross: arie
In general, net, and code commands may be distributed over the machines pluto, twain, kong, pleiades, mercury, ra, and venus.
The subsequent groups of lines specify machine architectures and additional specifications for each architecture. The architecture may be shown on a per-Summit/CM view/Rational subsystem basis by selecting a Summit/CM view/Rational subsystem and executing the Control > Reports > Properties command. The output field titled Host Architecture specifies the value for arch.The line beginning with cross indicates which machines can also perform cross compilations from the corresponding native architecture.
The machine pleiades is not associated with a particular arhitecture, this tells Apex it may only be used for non-architecture specific commands.
The machine mercury occurs twice in a machines list, this tells Apex to distribute multiple (two in this case) jobs to mercury.
The method keyword specifies that jobs distributed to alpha_osf1 machines use rsh and jobs distributed to i386_linx2 machines use ssh. In general on is the preferred method.
The link command may also be distributed for i386_linux2 and rs6k_aix.
Monitoring Distributed Compilation and Execution
To see machines running command servers for your Apex session:
- 1 . From the Jobs window, execute the Navigate > Servers command.
- 2 . In the Servers window, execute the View > Show Machine command.
Note: The first invocation of the code command for a new machine takes longer than subsequent ones due to the overhead of forking a command server.
To display information as the net command executes, from the Jobs window, execute the Tools > Net Command Info command.
Trouble Shooting the Distributed Compilation and Execution Facility
If Apex reports a machine is not responding, try running rsh or on from an Apex shell to that machine. (Choose rsh or on based on your execution file).
If Apex removes a machine from the set, that only applies for the duration of that command.
Apex will acquire locks on views as it compiles, to ensure the sanity of the compilation. This may cause distributed compilations to appear to hang. Organiztion of c/C++ views into layer_libraries can facilitate coding in parallel; the libraries (groups of views) may be compiled simultaneously, without interfeering with each other, by compiling the layer_library. For Ada views, coding imported views prior to coding importing views will make distributed compilation more effective.
Linking will also acquire locks on contributing views. Linking distribtution is more effective if all compilation, except for the main unit itself, is done prior to the link command. Distributed links of main units residing in the same view, will have little gain, as the links will still be basically serial.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |