idl2idl Compiler
For convenient processing of IDL-3 specifications together with CIDL
specifications, the compiler tool idl2idl is developed in this project.
In dependence from command line options, the tool provides the generation of
all required IDL and CIDL mappings.
The compilation of an IDL-3 specification, required for implementation
as well as for usage of a component, produces the following output :
- an IDL-2 specification, due to the fact, that the information processing of IDL-3
bases on mapping rules to equivalent IDL-2.4 specifications. This is in order to reuse the existing
language mappings of CORBA IDL for the implementation of stubs and skeletons. The specification comprises
external interfaces of the component (used by a client and to be implemented by servants)
and local interfaces (used by the interaction between container and component executors).
- a CIF container dependent C++ implementation for servants of the external components interfaces,
realizing the delegation of operations to the business code.
A file named name.idl results in name_implied.idl containing the equivalent IDL mapping and
Servants_name.h and Servants_name.cpp containing the container specific
servant implementations.
Currently unsupported IDL-3 features are :
The compilation of a CIDL specification produces the following output :
- skeleton code for C++ implementation classes of the component specific executor locator,
component specific executors or segments, the specific home executor and the
entry point function. As a CIDL specification defines the implementation structure of one or more
components, implementation code is generated for each CIDL composition.
A mapping from CIDL to C++ was developed in this project.
The developer only has to fill in the actual implementation code for IDL defined operations and can add
additional state members to the classes. In order to avoid the overwriting of
inserted user code in already generated classes by multiple generation from a
CIDL specification, we introduce special user code sections. This means, the
generator will produce meta comments into the skeleton files. Enclosed in the
comments <BEGIN USER INSERT SECTION name> and <END USER INSERT SECTION> the
user can place arbitrary user code. In subsequent compiler runs the contents
of these sections will be preserved in case the IDL element resulting in the
C++ construct which contains the section still exists in the IDL specification.
- a CORBA Component Descriptor file for each composition.
- an IDL specification containing the local interfaces for component executors and segments.
Those interfaces are needed if more than one interface has to be implemented by one class.
The compilation of a file named name.cidl results in local_object_name.idl for the local
IDL specification and produces for each specified composition a ccd file containing the CORBA Component Descriptor and
a header and cpp file containing the business code. The file names are build from the full qualification of the
composition, followed by the appropriate file suffix. A composition C in a module M results in
M_C.ccd, M_C.h and M_C.cpp.
Currently supported CIDL features are :
- composition,
- home executor,
- segment.
The usage of idl2idl offers several options. The command line is
idl2idl [options] filename where filename identifies an IDL-3 file (suffix idl) or a CIDL file
(suffix cidl). The most important options are :
- -b arg
- [ implementation code only for the composition arg]
- -c
- [ generate no servants ]
- -C
- [ generate no equivalent IDL ]
- -I arg
- [ include directory for IDL files ]