[omniORB] Nesting IDL files

[Quinlan, Mike]

Can you run your .idl file through the C preprocessor before running the IDL
compiler on it?

-----Original Message-----
From: Olaf Meding [mailto:olaf@tomotherapy.com]
Sent: Monday, April 23, 2001 11:06 AM
To: Duncan Grisby; omniORB Mailing List
Subject: RE: [omniORB] Nesting IDL files

Duncan,

> ... it's generally a very bad idea to use #include anywhere other than at
file-scope ...

Consider this approach.  We have a lot of code in a single module maintained
by multiple developers.  So we decided to have common code (shared by
multiple interfaces) in module1.idl and each interface has its own IDL file.
This has a number of advantages:

  - IDL compiler still produces only a single pair of stub files (or at
least other ORBs do).

  - Each developer has its own (interface) file.

  - This intuitively splits code into multiple files.

  - -D option is used to optionally include only interfaces needed by a
given application.  This way not all apps need to be recompiled if only a
single inferface (IDL file) changed.


To illustrate:

*** abreviated module1.idl ***
  module m1 {
    // losts of code shared by all of our IDL files

    #include "interface1.idl"

    #if defined( INTERFACE1_IDL )
    #include "interface2.idl"
    #endif

  }

*** abreviated interface1.idl ***
  interface i1 {
    // interface code
  };

I do not think that this is a "fragile" approach.  What is the alternative?
Put all code into a big IDL file since that are problems splitting code (for
a single module) into multiple IDL files?

Note, we are porting our code from OOC's ORBacus.  They have an IDL compiler
switch called "--all".  Here is the help for this switch: "Generate code for
included files instead of inserting #include statements".

Both omniORB and ORBacus use the GNU C preprocessor.  I wish there would be
a way to work around this problem, but I am not sure I have the time or
patience to modify either the GNU C preprocessor or the IDL compiler.


Any help is greatly appreciated.

Olaf

-----Original Message-----
From: owner-omniorb-list@uk.research.att.com
[mailto:owner-omniorb-list@uk.research.att.com]On Behalf Of Duncan
Grisby
Sent: Monday, April 23, 2001 11:18 AM
To: Olaf Meding
Cc: omniORB Mailing List
Subject: Re: [omniORB] Nesting IDL files


On Friday 20 April, "Olaf Meding" wrote:

> omniORB does not seem to deal with nested IDL files correctly or maybe I
am
> doing something wrong?  The IDL compiler has no problem compiling the main
> and nested idl files.  However, when I compile the files produced by the
IDL
> compiler with VC6 I get an error saying that a header file is missing.
The
> name of the header file is the name of the nested IDL file.
>
> Here is my (abreviated) IDL file:
>   module tcorba {
>     // losts of code shared by all of our IDL files
>
>     #include "name.idl"
>   }

omniidl's C++ back-end is somewhat broken when it comes to IDL like
this. However, it's generally a very bad idea to use #include anywhere
other than at file-scope, since it can lead to all sorts of problems.
It basically prevents any sort of separate compilation of IDL files,
since the definitions in name.idl only have the right C++ scoped names
if included from the file module tcorba is defined in. That's what
causes omniidl to do the wrong thing since it's trying to allow
separate compilation.

It's also very fragile. Imagine someone wants to use a type from the
CosNaming module in name.idl, so they add #include <Naming.idl> to the
to of name.idl. Now all the definitions from CosNaming should appear
in module tcorba!

I'll think about the best way that omniORB can have consistent
behaviour with this sort of IDL, but by far the best thing for
application authors to do is to avoid the issue and only #include at
file scope.

Cheers,

DUncan.

--
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --