The ic module is an Erlang implementation of an OMG IDL compiler. Depending on the choice of back-end the code will map to Erlang, C, or Java. The compiler generates client stubs and server skeletons.
Two kinds of files are generated for each scope: Ordinary code files and header files. The latter are used for defining record definitions, while the ordinary files contain the object interface functions.
The tuple
The
Example:
Places all output files in the directory given by the option. The directory will be created if it does not already exist.
Example option:
Uses FileName as configuration file. Options will
override compiler defaults but can be overridden by command line
options. Default value is
Example option:
Uses a preprocessor. Default value is true.
Command string to invoke the preprocessor. The actual
command will be built as
Example option:
Example option:
Flags given to the preprocessor.
Example option:
Currently, the default setting is
Example option:
Generate header files. Default is true.
Makes the last
Assumes that the interface with name IntfName is
implemented by the module with name ModName and
will generate calls to the ModName module in the
server behavior. Note that the IntfName must be a
fully scoped name as in
Adds the object reference as the first parameter to the
object implementation functions. This makes the
implementation aware of its own object reference.
The option
comes in three varieties:
Example option:
Example option:
Example options:
Adds the invokers reference as the first parameter to the
object implementation two-way functions. If both
The option
comes in three varieties:
Example option:
Example options:
Example options:
Makes the object server call a function
Example option:
Example option:
Example options:
Used to allow a server response time limit to be set by the user. This should be a string that represents the scope for the interface which should have an extra variable for wait time initialization.
Example option:
Example option:
Example options:
Used to produce more refined request calls to server. When
this option is set to true, the operation name which was
mentioned in the call is scoped. This is essential to avoid
name clashes when communicating with c-servers. This option
is available for the c-client, c-server and the Erlang
gen_server back ends.
Example options:
Used to define a own protocol different from the default
Erlang distribution + gen_server protocol. Currently only
valid for C back-ends. For further details see
Example options:
Makes sends and receives to have timeouts (C back-ends only). These timeouts are specified in milliseconds.
Example options:
Generates code for writing encode/decode errors to
Example options:
Used for compatibility with previous compiler versions up
to
Example option:
Adds a precondition call before the call to the operation implementation on the server side.
The option comes in three varieties:
The precondition function has the following signature
Example option:
Example options:
Example options:
Adds a postcondition call after the call to the operation implementation on the server side.
The option comes in three varieties:
The postcondition function has the following signature
Example option:
Example options:
Example options:
The option activates all reasonable warning messages in analogy with the gcc -Wall option. Default value is true.
The maximum numbers of errors that can be detected before
the compiler gives up. The option can either have an integer
value or the atom
The maximum numbers of warnings that can be detected before
the compiler gives up. The option can either have an integer
value or the atom
Suppresses all warnings. Default value is false.
Warning appears whenever names are shadowed due to inheritance; for example, if a type name is redefined from a base interface. Note that it is illegal to overload operation and attribute names as this causes an error to be produced. Default value is true.
Activates all warning options. Default value is false.
Suppresses compiler printed output. Default value is false.
Which back-end IC will generate code for is determined by the supplied
This option switches to the IDL generation for CORBA.
Generate CORBA call-back module templates for each interface in the target IDL file. Note, will overwrite existing files.
Will produce plain Erlang modules which contain functions that map to the corresponding interface functions on the input file.
This is an IDL to Erlang generic server generation option.
Will produce a C client to the generic Erlang server.
Will produce a C server switch with functionality of a generic Erlang server.
Will produce Java client stubs and server skeletons with functionality of a generic Erlang server.
Deprecated. Use
The IDL compiler allows several preprocessors to be used, the
The preprocessor command is formed by appending the prepoc_cmd to the preproc_flags option and then appending the input IDL file name.
The compiler can be configured in two ways:
Configuration file
Command line options
The configuration file is optional and overrides the compiler
defaults and is in turn overridden by the command line options.
The configuration file shall contain options in the form of
Erlang terms. The configuration file is read using
An example of a configuration file, note the "." after each line.
{outdir, gen_dir}.
{{impl, "M1::M2::object"}, "obj"}.
The compiler will produce output in several files depending on
scope declarations found in the IDL file. At most
three file types will be generated for each scope (including the top scope),
depending on the compiler back-end and the compiled interface.
Generally, the output per interface will be a header file (
There will be at least one set of files for an IDL file, for the file level scope. Modules and interfaces also have their own set of generated files.