Go to the previous, next section.

Using OMG IDL with ILU

The program idl2isl translates from IDL to ISL. IDL is the Interface Definition Language defined by the Object Management Group. (12) The program is derived from the Interface Definition Language Compiler Front End from SunSoft, Inc. (13)

Invocation

The program is run automatically as an intermediate step by any of the ILU tools that take ISL files (normally ending in `.isl') if the filename ends in `.idl'.

The program may also be run directly, with the following arguments:

idl2isl { -Wb,toggle | -Wb,!toggle }* source.idl
In this case, it writes the ISL to its standard output. A toggle is set with an argument -Wb,toggle and cleared with an argument -Wb,!toggle. Toggle settings may also be effected by setting the environment variable `IDL2ISL_OPTS' to a comma-separated list of toggle names, each of which is either preceded by a `!' character (which clears it) or not (which sets it). Command-line arguments take precedence over the environment variable settings.

The toggles are:

Translation

On the whole, the translation from IDL to ISL is a straightforward change of syntax. There are a few cases, however, where a bit extra is needed.

Anonymous types

IDL allows type declarators to be used in certain places in the syntax (for example, struct members and operation parameters). ISL does not; it requires a type name in the corresponding situations. As a result, it is sometimes necessary for the translator to introduce a name in the ISL output for those types that are anonymous in the IDL input. These names are always of the form AnonType-nnn-, where nnn is an integer.

For example, the IDL declaration

struct str {
	long	f1;
	long	f2[5];
};
is translated into the following ISL:
TYPE AnonType-1- = ARRAY OF 5 INTEGER;
TYPE str = RECORD
	f1 : INTEGER,
	f2 : AnonType-1-
	END;

Topmodules mode

When the translator is in this mode (which it is by default), only module declarations are allowed at the topmost level. Each module translates into an INTERFACE declaration in ISL, and the declarations inside each module go into the corresponding ISL INTERFACE.

If the translator is not in this mode, all the declarations in the IDL file go into one ISL INTERFACE whose name is taken from the IDL input filename, less the `.idl' suffix.

Imports mode

When the translator is in this mode (which it is by default), #include preprocessor directives are, roughly speaking, turned into ISL IMPORT statements. This mode allows for separate compilation (stub generation) of interfaces. There are some restrictions: the #include directives must occur before any declarations in the file, and the files that are included must not be fragments. That is, each must consist of a sequence of whole declarations (more specifically, module declarations if in topmodules mode). The included files may in turn include other files.

If the translator is not in this mode, the input is considered to be the result of preprocessing the file first and textually substituting the included files, following the usual behavior of C and C++ compilers.

Unsupported constructs

The IDL types Object and any are disallowed by the translator. Use of context clauses on operations is also prohibited.

Go to the previous, next section.