[omniORB] IDL stub topology in python

[Duncan Grisby]

On Friday 31 January, Thomas Lockhart wrote:

> I've been looking at packaging for python IDL and have a few questions 
> regarding the current behavior of omniidl. I'm hoping for some 
> suggestions on how to install these into production areas.

To understand why the stubs are arranged the way they are, you must
first read the Python mapping specification. In a nutshell, it says
that module A maps to stubs and type definitions in Python package A,
and skeletons in package A__POA. That's the reason for that
separation.

Now, consider that IDL modules can be reopened both in a single IDL
file, and in multiple files. Take the following evil declarations, for
example...

// one.idl

module A {
  interface I;
  interface J {
    I op1();
  };
};

module B {
  interface K {
    A::I op2();
  };
};

module A {
  interface I {
    J op3();
    B::K op4();
  };
};


// two.idl

#include "one.idl"

module A {
  interface L {
    A::I op5(in B::K k);
  };
};

module B {
  interface M {
    A::L op6();
  };
};


Despite being ugly, that is all legal IDL. If you reflect on that, and
think about the way Python imports modules, you will see that it is
impossible to put the definitions in the stubs directly inside the
packages required by the standard mapping, because to do so would
require that one of the modules had all of its declarations read in
first. That can't happen because there are circular dependencies
between the modules.

I can think of only two ways to avoid the problem. One is to emit a
single Python stub file for each IDL file, with declarations in the
order of the IDL file. That guarantees that any dependencies happen in
the right order, because otherwise the IDL would have been illegal.
That is the scheme that omniORBpy currently uses. The other option
would be to emit lots of small fragments, starting a new fragment
wherever necessary to mean the dependencies are resolved in the right
order. I decided that that was far too complicated and confusing. It
certainly isn't possible to put stub files inside the packages
required by the standard mapping.

I assume you have looked at the -Wbpackage, -Wbstubs and -Wbmodules
options that allow you to put the omniidl output in different places.
(Note that using -Wbpackage and -Wbmodules mean omniidl's output does
not adhere to the standard.)  If they don't do what you want, you can
force all the stubs for your entire project into a single file by
creating a file that #includes each IDL file, then using the -Wbinline
option to output definitions for all the includes in a single stub
file. You can then put that file into a suitable Python package using
-Wbstubs.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --