Sophie

Sophie

distrib > Fedora > 17 > i386 > media > updates > by-pkgid > 675c8c8167236dfcf8d66da674f931e8 > files > 713

erlang-doc-R15B-03.3.fc17.noarch.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- ic</title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
            <!--
              function getWinHeight() {
                var myHeight = 0;
                if( typeof( window.innerHeight ) == 'number' ) {
                  //Non-IE
                  myHeight = window.innerHeight;
                } else if( document.documentElement && ( document.documentElement.clientWidth ||
                                                         document.documentElement.clientHeight ) ) {
                  //IE 6+ in 'standards compliant mode'
                  myHeight = document.documentElement.clientHeight;
                } else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
                  //IE 4 compatible
                  myHeight = document.body.clientHeight;
                }
                return myHeight;
              }

              function setscrollpos() {
                var objf=document.getElementById('loadscrollpos');
                 document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
              }

              function addEvent(obj, evType, fn){
                if (obj.addEventListener){
                obj.addEventListener(evType, fn, true);
                return true;
              } else if (obj.attachEvent){
                var r = obj.attachEvent("on"+evType, fn);
                return r;
              } else {
                return false;
              }
             }

             addEvent(window, 'load', setscrollpos);

             //--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/ic-4.2.31.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>ic</strong><br><strong>Reference Manual</strong><br><small>Version 4.2.31</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Table of Contents</strong></small></p>
<ul class="flipMenu">
<li id="loadscrollpos" title="ic " expanded="true">ic<ul>
<li><a href="ic.html">
                  Top of manual page
                </a></li>
<li title="ic:gen-1"><a href="ic.html#ic:gen-1">ic:gen/1</a></li>
<li title="ic:gen-2"><a href="ic.html#ic:gen-2">ic:gen/2</a></li>
</ul>
</li>
<li id="no" title="ic_clib " expanded="false">ic_clib<ul>
<li><a href="ic_clib.html">
                  Top of manual page
                </a></li>
<li title="CORBA_Environment_alloc"><a href="ic_clib.html#CORBA_Environment_alloc">CORBA_Environment_alloc()
                </a></li>
<li title="CORBA_free"><a href="ic_clib.html#CORBA_free">CORBA_free()
                </a></li>
<li title="CORBA_string_alloc"><a href="ic_clib.html#CORBA_string_alloc">CORBA_string_alloc()
                </a></li>
<li title="CORBA_wstring_alloc"><a href="ic_clib.html#CORBA_wstring_alloc">CORBA_wstring_alloc()
                </a></li>
<li title="CORBA_exception_id"><a href="ic_clib.html#CORBA_exception_id">CORBA_exception_id()
                </a></li>
<li title="CORBA_exception_value"><a href="ic_clib.html#CORBA_exception_value">CORBA_exception_value()
                </a></li>
<li title="CORBA_exc_set"><a href="ic_clib.html#CORBA_exc_set">CORBA_exc_set()
                </a></li>
<li title="oe_server_receive"><a href="ic_clib.html#oe_server_receive">oe_server_receive()
                </a></li>
<li title="oe_server_receive_tmo"><a href="ic_clib.html#oe_server_receive_tmo">oe_server_receive_tmo()
                </a></li>
<li title="oe_exec_switch"><a href="ic_clib.html#oe_exec_switch">oe_exec_switch()
                </a></li>
<li title="oe_merge_maps"><a href="ic_clib.html#oe_merge_maps">oe_merge_maps()
                </a></li>
</ul>
</li>
<li id="no" title="ic_c_protocol " expanded="false">ic_c_protocol<ul>
<li><a href="ic_c_protocol.html">
                  Top of manual page
                </a></li>
<li title="oe_prepare_notification_encoding"><a href="ic_c_protocol.html#oe_prepare_notification_encoding">oe_prepare_notification_encoding()
                </a></li>
<li title="oe_send_notification"><a href="ic_c_protocol.html#oe_send_notification">oe_send_notification()
                </a></li>
<li title="oe_send_notification_tmo"><a href="ic_c_protocol.html#oe_send_notification_tmo">oe_send_notification_tmo()
                </a></li>
<li title="oe_prepare_request_encoding"><a href="ic_c_protocol.html#oe_prepare_request_encoding">oe_prepare_request_encoding()
                </a></li>
<li title="oe_send_request_and_receive_reply"><a href="ic_c_protocol.html#oe_send_request_and_receive_reply">oe_send_request_and_receive_reply()
                </a></li>
<li title="oe_send_request_and_receive_reply_tmo"><a href="ic_c_protocol.html#oe_send_request_and_receive_reply_tmo">oe_send_request_and_receive_reply_tmo()
                </a></li>
<li title="oe_prepare_reply_decoding"><a href="ic_c_protocol.html#oe_prepare_reply_decoding">oe_prepare_reply_decoding()
                </a></li>
<li title="oe_prepare_request_decoding"><a href="ic_c_protocol.html#oe_prepare_request_decoding">oe_prepare_request_decoding()
                </a></li>
<li title="oe_prepare_reply_encoding"><a href="ic_c_protocol.html#oe_prepare_reply_encoding">oe_prepare_reply_encoding()
                </a></li>
</ul>
</li>
</ul>
</div></div>
<div id="content">
<div class="innertube">
<!-- refpage --><center><h1>ic</h1></center>
  
  <h3>MODULE</h3>
<div class="REFBODY">ic</div>
  <h3>MODULE SUMMARY</h3>
<div class="REFBODY">The Erlang IDL Compiler</div>
  <h3>DESCRIPTION</h3>
<div class="REFBODY"><p>
    <p>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.</p>
    <p>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.</p>
  </p></div>
  <h3>EXPORTS</h3>
    <p><a name="ic:gen-1"><span class="bold_code">ic:gen(FileName) -&gt; Result</span></a><br><a name="ic:gen-2"><span class="bold_code">ic:gen(FileName, [Option]) -&gt; Result</span></a><br></p>
<div class="REFBODY">
<p>Types:</p>
        <div class="REFTYPES">
<span class="bold_code">Result = ok | error | {ok, [Warning]} | {error, [Warning], [Error]}</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code"></span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">Option = [ GeneralOption | CodeOption | WarningOption | BackendOption]</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code"></span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">GeneralOption = </span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{outdir, String()} | {cfgfile, String()} | {use_preproc, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{preproc_cmd, String()} | {preproc_flags, String()}</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code"></span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">CodeOption =</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{gen_hrl, bool()} | {serv_last_call, exception | exit} | {{impl, String()}, String()} | {light_ifr, bool()}</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">this | {this, String()} | {{this, String()}, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">from | {from, String()} | {{from, String()}, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">handle_info | {handle_info, String()} | {{handle_info, String()}, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">timeout | {timeout, String()} | {{timeout, String()}, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{scoped_op_calls, bool()} | {scl, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{user_protocol, Prefix} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{c_timeout, {SendTimeout, RecvTimeout}} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{c_report, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{precond, {atom(), atom()}} | {{precond, String()} {atom(), atom()}} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{postcond, {atom(), atom()}} | {{postcond, String()} {atom(), atom()}}</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code"></span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">WarningOption =</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{'Wall', bool()} | {maxerrs, int() | infinity} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{maxwarns, int() | infinity} | {nowarn, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{warn_name_shadow, bool()} | {pedantic, bool()} |</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">{silent, bool()}</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code"></span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">BackendOption = {be, Backend}</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code"></span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">Backend = erl_corba | erl_template | erl_plain | erl_genserv | c_client | c_server | java</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code"></span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">DirNAme = string() | atom()</span><br>
</div>
        <div class="REFTYPES">
<span class="bold_code">FileName = string() | atom()</span><br>
</div>
      </div>
<div class="REFBODY"><p>
        <p>The tuple <span class="code">{Option, true}</span> can be replaced by
          <span class="code">Option</span> for boolean values.</p>
        <p>The <span class="code">ic:gen/2</span> function can be called from the command 
          line as follows:</p>
        <p><span class="code">erlc "+Option" ... File.idl</span></p>
        <p>Example:</p>
        <p><span class="code">erlc "+{be,c_client}"  '+{outdir, "../out"}' File.idl</span></p>
      </p></div>
  

  <h3><a name="id59778">General options</a></h3>
<div class="REFBODY">
    
    <dl>
      <dt><strong><strong>outdir</strong></strong></dt>
      <dd>
        <p>Places all output files in the directory given by the option.
          The directory will be created if it does not already exist.</p>
        <p>Example option: <span class="code">{outdir, "output/generated"}</span>.</p>
      </dd>
      <dt><strong><strong>cfgfile</strong></strong></dt>
      <dd>
        <p>Uses <strong>FileName</strong> as configuration file. Options will
          override compiler defaults but can be overridden by command line
          options. Default value is <span class="code">".ic_config"</span>.</p>
        <p>Example option: <span class="code">{cfgfile, "special.cfg"}</span>.</p>
      </dd>
      <dt><strong><strong>use_preproc</strong></strong></dt>
      <dd>
        <p>Uses a preprocessor. Default value is true.</p>
      </dd>
      <dt><strong><strong>preproc_cmd</strong></strong></dt>
      <dd>
        <p>Command string to invoke the preprocessor. The actual
          command will be built as
          <span class="code">preproc_cmd++preproc_flags++FileName</span></p>
        <p>Example option: <span class="code">{preproc_cmd, "erl"})</span>.</p>
        <p>Example option: <span class="code">{preproc_cmd, "gcc -x c++ -E"}</span>.</p>
      </dd>
      <dt><strong><strong>preproc_flags</strong></strong></dt>
      <dd>
        <p>Flags given to the preprocessor.</p>
        <p>Example option: <span class="code">{preproc_flags, "-I../include"}</span>.</p>
      </dd>
    </dl>
  </div>

  <h3><a name="id61360">Code options</a></h3>
<div class="REFBODY">
    
    <dl>
      <dt><strong><strong>light_ifr</strong></strong></dt>
      <dd>
        <p>Currently, the default setting is <span class="code">false</span>. To be able to
          use this option Orber must be configured to use Light IFR (see
          Orber's User's Guide). When this options is used, the size of the
          generated files used to register the API in the IFR DB are minimized.</p>
        <p>Example option: <span class="code">{light_ifr, true}</span>.</p>
      </dd>
      <dt><strong><strong>gen_hrl</strong></strong></dt>
      <dd>
        <p>Generate header files. Default is true.</p>
      </dd>
      <dt><strong><strong>serv_last_call</strong></strong></dt>
      <dd>
        <p>Makes the last <span class="code">gen_server handle_call</span> either raise a
          CORBA exception or just  exit plainly. Default is the exception.
          </p>
      </dd>
      <dt><strong><strong>{{impl, IntfName}, ModName}</strong></strong></dt>
      <dd>
        <p>Assumes that the interface with name <strong>IntfName</strong> is
          implemented by the module with name <strong>ModName</strong> and
          will generate calls to the <strong>ModName</strong> module in the
          server behavior.  Note that the <strong>IntfName</strong> must be a
          fully scoped name as in <span class="code">"M1::I1"</span>.</p>
        <p></p>
      </dd>
      <dt><strong><strong>this</strong></strong></dt>
      <dd>
        <p>Adds the object reference as the first parameter to the
          object implementation functions. This makes the
          implementation aware of its own object reference. 
                    <br>
The option
          comes in three varieties: <span class="code">this</span> which activates the
          parameter for all interfaces in the source file, <span class="code">{this, IntfName}</span> which activates the parameter for a specified
          interface and <span class="code">{{this, IntfName}, false}</span> which
          deactivates the parameter for a specified
          interface.</p>
        <p>Example option: <span class="code">this)</span> activates the parameter for
          all interfaces.</p>
        <p>Example option: <span class="code">{this, "M1::I1"}</span> activates the
          parameter for all functions of <span class="code">M1::I1</span>.</p>
        <p>Example options: <span class="code">[this, {{this, "M1::I2"}, false}]</span>
          activates the parameter for all interfaces except
          <span class="code">M1::I2</span>.</p>
      </dd>
      <dt><strong><strong>from</strong></strong></dt>
      <dd>
        <p>Adds the invokers reference as the first parameter to the
          object implementation two-way functions. If both
          <span class="code">from</span> and <span class="code">this</span> options are used the invokers
          reference parameter will be passed as the second
          parameter. This makes it possible for the implementation to
          respond to a request and continue executing
          afterwards. Consult the <span class="code">gen_server</span> and <span class="code">Orber</span>
          documentation how this option may be used.            <br>
The option
          comes in three varieties: <span class="code">from</span> which activates the
          parameter for all interfaces in the source file, <span class="code">{from, IntfName}</span> which activates the parameter for a specified
          interface and <span class="code">{{from, IntfName}, false}</span> which
          deactivates the parameter for a specified interface.</p>
        <p>Example option: <span class="code">from)</span> activates the parameter for
          all interfaces.</p>
        <p>Example options: <span class="code">[{from, "M1::I1"}]</span> activates the
          parameter for all functions of <span class="code">M1::I1</span>.</p>
        <p>Example options: <span class="code">[from, {{from, "M1::I2"}, false}]</span>
          activates the parameter for all interfaces except
          <span class="code">M1::I2</span>.</p>
      </dd>
      <dt><strong><strong>handle_info</strong></strong></dt>
      <dd>
        <p>Makes the object server call a function <span class="code">handle_info</span>
          in the object implementation module on all unexpected
          messages. Useful if the object implementation need to trap
          exits.</p>
        <p>Example option: <span class="code">handle_info</span> will activates module
          implementation <span class="code">handle_info</span> for all interfaces in the
          source file.</p>
        <p>Example option: <span class="code">{{handle_info, "M1::I1"}, true}</span>
          will activates module implementation <span class="code">handle_info</span> for
          the specified interface.</p>
        <p>Example options: <span class="code">[handle_info, {{handle_info, "M1::I1"}, false}]</span> will generate the <span class="code">handle_info</span>
          call for all interfaces except <span class="code">M1::I1</span>.</p>
      </dd>
      <dt><strong><strong>timeout</strong></strong></dt>
      <dd>
        <p>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.</p>
        <p>Example option: <span class="code">{timeout,"M::I"})</span> produces server
          stub which will has an extra timeout parameter in the initialization 
          function for that interface.</p>
        <p>Example option: <span class="code">timeout</span> produces server
          stub which will has an extra timeout parameter in the initialization 
          function for all interfaces in the source file.</p>
        <p>Example options: <span class="code">[timeout, {{timeout,"M::I"}, false}]</span>
          produces server stub which will has an extra timeout
          parameter in the initialization function for all interfaces
          except <span class="code">M1::I1</span>.</p>
      </dd>
      <dt><strong><strong>scoped_op_calls</strong></strong></dt>
      <dd>
        <p>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. <span class="code">All</span> of the parts generated by ic
          have to agree in the use of this option. Default is
          <span class="code">false</span>.  </p>
        <p>Example options:
          <span class="code">[{be,c_genserv},{scoped_op_calls,true}])</span> produces
          client stubs which sends "scoped" requests to a gen_server
          or a c-server.</p>
      </dd>
      <dt><strong><strong>user_protocol</strong></strong></dt>
      <dd>
        <p>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 <span class="bold_code"><a href="ic_c_protocol.html">IC C protocol</a></span>.</p>
        <p>Example options:
          <span class="code">[{be,c_client},{user_protocol, "my_special"}])</span> produces
          client stubs which use C protocol functions with the prefix 
          "my_special".</p>
      </dd>
      <dt><strong><strong>c_timeout</strong></strong></dt>
      <dd>
        <p>Makes sends and receives to have timeouts (C back-ends only).  These
          timeouts are specified in milliseconds. </p>
        <p>Example options:
          <span class="code">[{be,c_client},{c_timeout, {10000, 20000}}])</span> produces
          client stubs which use a 10 seconds send timeout, and a
          20 seconds receive timeout.</p>
      </dd>
      <dt><strong><strong>c_report</strong></strong></dt>
      <dd>
        <p>Generates code for writing encode/decode errors to <span class="code">stderr</span> (C back-ends only).
          timeouts are specified in milliseconds. </p>
        <p>Example options:
          <span class="code">[{be,c_client}, c_report])</span>.</p>
      </dd>
      <dt><strong><strong>scl</strong></strong></dt>
      <dd>
        <p>Used for compatibility with previous compiler versions up
          to <span class="code">3.3</span>.  Due to better semantic checks on enumerants,
          the compiler discovers name clashes between user defined
          types and enumerant values in the same name space. By
          enabling this option the compiler turns off the extended
          semantic check on enumerant values.  Default is
          <span class="code">false</span>.  </p>
        <p>Example option: <span class="code">{scl,true}</span></p>
      </dd>
      <dt><strong><strong>precond</strong></strong></dt>
      <dd>
        <p>Adds a precondition call before the call to the operation
          implementation on the server side.</p>
        <p>The option comes in three varieties: <span class="code">{precond, {M, F}}</span> which activates the call for operations in all
          interfaces in the source file, <span class="code">{{precond, IntfName}, {M, F}}</span> which activates the call for all operations in a
          specific interface and <span class="code">{{precond, OpName}, {M, F}}</span>
          which activates the call for a specific operation.</p>
        <p>The precondition function has the following signature
          <span class="code">m:f(Module, Function, Args)</span>.</p>
        <p>Example option: <span class="code">{precond, {mod, fun}}</span> adds the call
          of m:f for all operations in the idl file.</p>
        <p>Example options: <span class="code">[{{precond, "M1::I"}, {mod, fun}}]</span>
          adds the call of <span class="code">m:f</span> for all operations in the
          interface <span class="code">M1::I1</span>.</p>
        <p>Example options: <span class="code">[{{precond, "M1::I::Op"}, {mod, fun}}]</span> adds the call of <span class="code">m:f</span> for the operation
          <span class="code">M1::I::Op</span>.</p>
      </dd>
      <dt><strong><strong>postcond</strong></strong></dt>
      <dd>
        <p>Adds a postcondition call after the call to the operation
          implementation on the server side. </p>
        <p>The option comes in three varieties: <span class="code">{postcond, {M, F}}</span> which activates the call for operations in all
          interfaces in the source file, <span class="code">{{postcond, IntfName}, {M, F}}</span> which activates the call for all operations in a
          specific interface and <span class="code">{{postcond, OpName}, {M, F}}</span>
          which activates the call for a specific operation.</p>
        <p>The postcondition function has the following signature
          <span class="code">m:f(Module, Function, Args, Result)</span>.</p>
        <p>Example option: <span class="code">{postcond, {mod, fun}}</span> adds the call
          of m:f for all operations in the idl file.</p>
        <p>Example options: <span class="code">[{{postcond, "M1::I"}, {mod, fun}}]</span>
          adds the call of <span class="code">m:f</span> for all operations in the
          interface <span class="code">M1::I1</span>.</p>
        <p>Example options: <span class="code">[{{postcond, "M1::I::Op"}, {mod, fun}}]</span> adds the call of <span class="code">m:f</span> for the operation
          <span class="code">M1::I::Op</span>.</p>
      </dd>
    </dl>
  </div>

  <h3><a name="id59469">Warning options</a></h3>
<div class="REFBODY">
    
    <dl>
      <dt><strong><strong>'Wall'</strong></strong></dt>
      <dd>
        <p>The option activates all reasonable warning messages  in
          analogy with the gcc -Wall option. Default value is true.</p>
      </dd>
      <dt><strong><strong>maxerrs</strong></strong></dt>
      <dd>
        <p>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 <span class="code">infinity</span>. Default number is 10.</p>
      </dd>
      <dt><strong><strong>maxwarns</strong></strong></dt>
      <dd>
        <p>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 <span class="code">infinity</span>. Default value is
          infinity.</p>
      </dd>
      <dt><strong><strong>nowarn</strong></strong></dt>
      <dd>
        <p>Suppresses all warnings. Default value is false.</p>
      </dd>
      <dt><strong><strong>warn_name_shadow</strong></strong></dt>
      <dd>
        <p>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. </p>
      </dd>
      <dt><strong><strong>pedantic</strong></strong></dt>
      <dd>
        <p>Activates all warning options. Default value is false.</p>
      </dd>
      <dt><strong><strong>silent</strong></strong></dt>
      <dd>
        <p>Suppresses compiler printed output. Default value is false.</p>
      </dd>
    </dl>
  </div>

  <h3><a name="id59595">Back-End options</a></h3>
<div class="REFBODY">
    
    <p>Which back-end IC will generate code for is determined by the supplied
      <span class="code">{be,atom()}</span> option. If left out, <span class="code">erl_corba</span> is used.
      Currently, IC support the following back-ends:</p>
    <dl>
      <dt><strong><strong>erl_corba</strong></strong></dt>
      <dd>
        <p>This option switches to the IDL generation for CORBA.</p>
      </dd>
      <dt><strong><strong>erl_template</strong></strong></dt>
      <dd>
        <p>Generate CORBA call-back module templates for each interface in the target
          IDL file. Note, will overwrite existing files.</p>
      </dd>
      <dt><strong><strong>erl_plain</strong></strong></dt>
      <dd>
        <p>Will produce plain Erlang modules which contain functions that
          map to the corresponding interface functions on the input file.</p>
      </dd>
      <dt><strong><strong>erl_genserv</strong></strong></dt>
      <dd>
        <p>This is an IDL to Erlang generic server generation option.</p>
      </dd>
      <dt><strong><strong>c_client</strong></strong></dt>
      <dd>
        <p>Will produce a C client to the generic Erlang server.</p>
      </dd>
      <dt><strong><strong>c_server</strong></strong></dt>
      <dd>
        <p>Will produce a C server switch with functionality of a
          generic Erlang server.</p>
      </dd>
      <dt><strong><strong>java</strong></strong></dt>
      <dd>
        <p>Will produce Java client stubs and server skeletons with
          functionality of a generic Erlang server.</p>
      </dd>
      <dt><strong><strong>c_genserv</strong></strong></dt>
      <dd>
        <p>Deprecated. Use <span class="code">c_client</span> instead.</p>
      </dd>
    </dl>
  </div>

  <h3><a name="id59723">Preprocessor</a></h3>
<div class="REFBODY">
    
    <p>The IDL compiler allows several preprocessors to be used, the
      <span class="code">Erlang IDL preprocessor</span> or other standard <span class="code">C</span> preprocessors.
      Options can  be used to provide extra flags such as include
      directories to the preprocessor.  The build in the Erlang IDL
      preprocessor is used by default, but any standard  C preprocessor
      such as <span class="code">gcc</span> is adequate.</p>
    <p>The preprocessor command is formed by appending the prepoc_cmd
      to the preproc_flags option and then appending the input IDL
      file name.</p>
  </div>

  <h3><a name="id59752">Configuration</a></h3>
<div class="REFBODY">
    
    <p>The compiler can be configured in two ways:</p>
    <ul>
      <li>
        <p>Configuration file</p>
      </li>
      <li>
        <p>Command line options</p>
      </li>
    </ul>
    <p>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
      <span class="code">file:consult</span>.</p>
    <p>An example of a configuration file, note the "." after each
      line.</p>
    <div class="example"><pre>
{outdir, gen_dir}.
{{impl, "M1::M2::object"}, "obj"}.
    </pre></div>
  </div>

  <h3><a name="id64847">Output files</a></h3>
<div class="REFBODY">
    
    <p>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 (<span class="code">.hrl</span>/
      <span class="code">.h</span>) and one or more Erlang/C files (<span class="code">.erl</span>/<span class="code">.c</span>).
      Please look at the language mapping for each back-end for details.</p>
    <p>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.</p>
  </div>
  
</div>
<div class="footer">
<hr>
<p>Copyright © 1998-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>