[omniORB] Implementing a python version of Txn::Current

[Duncan Grisby]

On Tuesday 25 February, Thomas Lockhart wrote:

> o You had already indicated that it was OK to fold the existing stub 
> generation into a more extensive build of most IDL. At the moment, 
> CosNaming appears to be generated on the fly even though 
> python/CosNaming/__init__.py is in the tarball. python/CosNaming_idl.py 
> does not exist so it would seem that the __init__.py file is overwritten 
> during build. Correct?

Correct. I'm sure there was a very good reason for that file being in
the CVS repository, but I can't remember what it was.

> o PortableServer seems to be not directly generated from IDL. Is there 
> hand-written code in the files in the tarball? If so I should leave 
> PortableServer.idl out of my list of generated stubs. Right?

You've already figured this out, but in case anyone else is
interested, PortableServer.idl is pseudo IDL, not real IDL. The
PortableServer.py file is (almost) completely hand-written.

> o Do you prefer to use the stub/ directory to hold auto-generated stubs? 
>   I can make this work, though it is a bit crufty to have the build 
> originate in python/ and then put the stubs in $(CORBA_STUB_DIR) (aka 
> stub/) since the rules now must include the target directory.

No. The stub directory is a hold-over from history, and is used by the
C++ examples. Don't jump through hoops to use it for Python.

> o If using the stub/ directory (and even if not), should I modify the 
> extensive rules in beforeauto.mk.in and afterauto.mk.in which are 
> borrowed from omniORB?

I'd strongly recommend not changing beforeauto.mk.in /
afterauto.mk.in.  They are a horrible mess, and adding new things to
them, however clean, will not help.

>   Or should I just write other rules in 
> python/dir.mk to avoid mucking about with the layers of rules resulting 
> from the three generations of build systems used for omniORB?

Yes. In fact, I'd suggest creating a new directory under python/ that
is used to build the stubs, so the makefile in there only deals with
stubs.

> >>Just curious, why is it an omniORBpy 2.1 release rather than 2.0.1?
> > No particular reason. The trend started when I decided to release 1.1
> > after 1.0, as a way to increase the version number more rapidly. :-)
> 
> So why not take the big leap and do the same for omniORB itself? Leave 
> the "minor minor" release numbers for bugfix only releases...

The C++ ORB has a well defined meaning for major, minor, micro
versions. Changes in micro version do not require a recompile of
application code; changes in minor version do require a recompile, but
require no source code changes; changes in major version may require
application source code changes. There are currently no such rules for
omniORBpy. Version numbers are pretty arbitrary things, anyway.

Cheers,

Duncan.

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