[omniORB] omniidl -bpython bug

[Luke Deller]

On Tue, 2005-09-27 at 12:39 +1000, Luke Deller wrote:
> In the case where two IDL files contribute to the same CORBA module, and
> a third IDL file #include's one of those IDL files, then "omniidl
> -bpython" generates wrong stubs.  Here's an example:
...
> Perhaps omniORB.openModule should use __import__ rather than
> imp.new_module ?

On further analysis, this suggestion is not a correct solution.  It can
fail when circularities exist between modules (eg an interface in module
A extends an interface in module B, and vice versa) because it would now
introduce circular imports among the python stubs.

The only solution we have thought of so far relies on the fact that
there are no circularities in #include's between IDL files.  A python
stub file can be built for each IDL file, much the same as it is done
currently, but instead of trying to build up the python module heirarchy
at that time, it could just expose a variable describing all the objects
which this IDL file contributes to various python packages.  The
__init__.py files which are laid out according to the required python
module heirarchy currently import the relevant stub files.  They could
additionally copy the relevant objects from each stub file's descriptor
variable into their own namespace.  In this scheme, the (per-IDL-file)
stub files would not access the (per-CORBA-module) python modules at
all.

Is there no smaller modification which could fix this problem?  Want me
to have a go at implementing the above in omniidl's python backend?

Regards,
Luke.

**********************************************************************************************

Important Note
This email (including any attachments) contains information which is
confidential and may be subject to legal privilege.  If you are not
the intended recipient you must not use, distribute or copy this
email.  If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this
email are not necessarily the views of XPlan Technology.

It is the duty of the recipient to virus scan and otherwise test the
information provided before loading onto any computer system.
Xplan Technology does not warrant that the
information is free of a virus or any other defect or error.
**********************************************************************************************