[omniORB] Nesting IDL files

[Olaf Meding]

Duncan,

I tried your suggestions but am confused.  common.idl is included at the top
of the interface.idl file (see below).  So why I need to tell the IDL
compiler to compile common.idl file seperately?

  // common.idl
  module m1 {
    // common code...
  };

  // interface1.idl
  #include <common.idl>
  module m1 {
    interface i1 {
      ...
    };
  };


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 12:17 PM
To: Olaf Meding
Cc: omniORB Mailing List
Subject: Re: [omniORB] Nesting IDL files


On Monday 23 April, "Olaf Meding" wrote:

> 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:

You get exactly the same effect by reopening the modules:

  // common.idl
  module m1 {
    // common code...
  };

  // interface1.idl
  #include <common.idl>
  module m1 {
    interface i1 {
      ...
    };
  };

and so on.

If you want to keep the ability to use -D to optionally include
things, you can have

  // master.idl
  #include <common.idl>

  #if defined (INTERFACE1_IDL)
  #include <interface1.idl>
  #endif

and so on.

This also has the significant advantage that all ORBs will agree about
what the repository identifiers for the types are. The CORBA spec says
that in

  // a.idl
  module A {
    #include "b.idl"
  };

  // b.idl
  interface I {};

the repository id of interface I should be "IDL:I:1.0", but many ORBs
will incorrectly set it to "IDL:A/I:1.0". That would cause an
interoperability problem between conforming and non-conforming ORBs.
Going the module reopening route avoids this problem. omniidl is one
of the few IDL compilers which gets it right.


> 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".

That approach would work for omniidl, and the Python back-end already
supports it. It wouldn't be too hard to add it to the C++ back-end.

I still think it's best to avoid #include inside modules.

Cheers,

Duncan.

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