[omniORB] Python2.0

[Duncan Grisby]

On Monday 15 October, Michel Sanner wrote:

> 1 - The building script assumes that sys.prefix is the same as
> sys.exec_prefix.  When sys.prefix is different from sys.exec_prefix
> config.h is found in sys.exec_prefix/include/python$(VERSION)/ while
> all the other Python include files are in
> sys.prefix/include/python$(VERSION)/. The consequence is that one
> has to use -Isys.exec_prefix/include/python$(VERSION)/ AND
> -Isys.prefix/include/python$(VERSION)/ on the compilation line of
> tool/omniidl/cxx/idlpython.cc

I guess that just goes to show that the vast majority of Python
installations have the same sys.prefix as sys.exec_prefix. I've fixed
the make rules in CVS.

> 2 - the script in ./bin/<platform>/omniidlrun.py starts with
> #!/usr/bin/env python
> 
> which assumes that "python" resolves to the proper version of
> Python. Since you are asking where the Python interpreter is anyways
> in the <platfomr>.mk file, why not use the path to the interpreter
> that was specified there ?

This is one aspect of the wider issue that the omniORB build
environment is an over-complex mess. We intend to rework it before the
4.0 release. Fixing this particular problem involves rewriting the
headers of .py files, so it's a but ugly.

> 3 - during gmake export intr ./scr the make command in
> src/lib/omniORB2 fails because the python interpreter invoked by
> omniidlrun.py does not find _omniidlmodule.so. I added the ./lib
> directory to sys.path in omniidlrun.py. I did not want to add it to
> PYTHONPATH becaue this variable is seen by all my python
> interpreters (1.5.2, 2.0, .2.1, 2.2 etc..)

I don't understand why that's a problem -- omniidlrun.py already tries
quite hard to set the paths so you don't need to set PYTHONPATH. What
exactly did you add to it?

> 4 - I understand that omniORB uses Python internally. Does this version of 
> Python have to math the one with which omniORBpy is used ?

omniORB only uses Python for the IDL compiler. There is no reason for
it to be the same version of Python as you are using with omniORBpy.
You do need to be careful to compile _omniidlmodule.so against the
version of Python you are using for omniidl and _omnipymodule.so
against the version you are using with omniORBpy, because different
Python releases have different internal API layouts.

Cheers,

Duncan.

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