[omniORB] multiple directories for generated IDL

Duncan Grisby duncan at grisby.org
Fri Sep 19 17:21:55 BST 2003


On Wednesday 17 September, "Brian C. Olson" wrote:

[ Please don't send evil HTML mail to the omniORB list. ]

> I have a reason to generate parts of IDL modules into different
> directories.  Basically, we have some standard IDL that I have
> pre-generated and installed into site-packages using a command like:

[...]

> The problem is that although omniidl can find the IDL files and
> generate the directory, python thinks there is only one place to
> find the import for coolproduct.modulex. Once it finds either my
> local copy or the site-packages copy it won't look for the other
> one. Since they both contain parts of modulex, they both need to be
> found.

That's just a consequence of the way Python imports work.

> I can solve this by making my python path find the local one first and
> modifying the module paths by changing the omniidl generated versions of
> __init__.py in the local directory to include the incantation:
>  
> from pkgutil import extend_path
> __path__ = extend_path(__path__, __name__)

This incantation requires magic that's newly available in Python 2.3.

> This seems evil since it is right below a line that says "# DO NOT
> EDIT THIS FILE!"

It's actually perfectly safe to edit the file that way, and future
omniidl runs won't overwrite it. The dire warnings are just to stave
off the problems from people who edit it in dangerous ways...

> Is there another way to make this work, and if not, would this be
> useful to have an option to generate the extend_path incantations in
> the generated __init__.py files?

In complex cases like this, I'd recommend importing stubs directly
using the *_idl.py files, rather than on the IDL defined module names.
That way you know exactly what you're getting.

Cheers,

Duncan.

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



More information about the omniORB-list mailing list