[omniORB] OmniORBpy separate compiles & #included files

[Duncan Grisby]

On Thursday 13 January, Richard Gruet wrote:

[...original IDL moved to the end...]

> In the former case, I can as expected access foo() with:
> import A
> A.B.I.foo()
> but not in the latter case.

Using #include inside IDL constructs, rather than at global scope,
causes all sorts of problems for the various language bindings. This
is only one of them.

The quick fix for you is to use the (so far undocumented) -Wbinline
flag to omniidl, which generates the stubs for all included IDL files
in a single file:

  omniidl -bpython -Wbinline X.idl


I could modify the compiled stubs (and I think I will) so that the
particular problem you're having is avoided, but there is no complete
solution. Consider:

// one.idl
module A {
  module B {
    #include "two.idl"
  };
};

// two.idl
module A {
  interface I {};
};

Now, if I separately compile two.idl, it's going to try to create a
top-level Python package named A, since it can't possibly know that
it's intended to be used by inclusion in one.idl. Unfortunately,
that's the same package A used by one.idl!  Oh dear.

What if one.idl is the same, and two.idl is just:

// two.idl
interface I {};

Compiling two.idl will create a package named _GlobalIDL with I inside
it. Now what happens when two.idl is included in one.idl?  Do the
definitions from _GlobalIDL magically appear inside A.B?

Basically, I think the proper way to cope with #includes inside
modules is to generate a single stub file.

> I have a project with a lot of IDL files organized in such a way, and I
> had to preprocess them
> (with omniidl -E) -and remove the # comments!- to get the proper result.

Unfortunately, that will give you the wrong result!  The IDL
specification (actually the Interface Repository chapter, but that's
just bad organisation) says that in the first case, the repository
identifier of interface I is IDL:A/B/I:1.0, but in the second it's
just IDL:B/I:1.0.


> PS: I greatly appreciate omniORBpy that I find very stable and
> performant so far, and that I plan to use extensively in my project
> (being a Python afficionado and a distributed computing evangelist).

Thanks :-)

Duncan.


[... original IDL from the top of the message ...]

> [X.idl]
> module A {
>     module B {
>         interface I {
>             void foo();
>         };
>     };
> };

> [X.idl]:
> module A {
> #include "Y.idl"
> }
> 
> [Y.idl]
> module B {
>     interface I {
>         void foo();
>    };
> };



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