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

[Thomas Lockhart]

> If you get it done in the next few days, and it doesn't break
> anything, I'll include your changes...

OK. Since there is a deadline, and since I haven't contributed (much) 
code to omniORB yet, I'll ask a few questions to figure out what "break" 
means to you ;)

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?

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?

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.

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? 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? I'm happy 
to modify stuff in mk/, but didn't want to dive in and discover that you 
would prefer I stay away from that. I'm happy to continue with the 
hyper-general style of build rules in mk/, but if it is fair game to 
simplify it I'll consider doing that. Guidance?

>>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...

                     - Tom