[omniORB] Patch for OpenVMS

[Bruce Visscher]

Duncan,

Attached, please find a patch that applies to omniORB 4.1.5, a patch
that applies to omniORBpy 3.5. These files are primarily for the
OpenVMS(*) platform.

The omniORB patch allows the (Open)VMS platform to be configured to
use poll rather than select. It also provides handling of certain
error condition that sometimes occurs on this platform.

I also made some changes in the way exceptions are thrown from the
omniORB library. Rather than having a macro that calls a function
that throws and exception, I modified the function to return the
exception and the macro to throw the result. The reason for doing
this is that the HP C++ compiler on VMS does some flow analysis to
determine that certain branches won't return a value from a function.
Unfortunately, there isn't any way in C++ to express that a function
always throws an exception so this would confuse the compiler. I hope
this change is acceptable. If not then I could modify the build
system to suppress the warning. (On VMS, all compiler warnings are
harmful.)

I browsed the SVN source tree and I don't think there is any overlap
with the latest code in development but I am not certain of that.

I was also going to send an updated etc/openvms.zip file but gmail
brokenly thinks that zip files are executable files so it won't let
me. I will have to find another way.

Bruce

(*) OpenVMS is a marketing term.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniORB-4.1.5.vms.diff
Type: application/octet-stream
Size: 15284 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110609/6d669d07/omniORB-4.1.5.vms.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniORBpy-3.5.vms.diff
Type: application/octet-stream
Size: 1209 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110609/6d669d07/omniORBpy-3.5.vms.obj

[Duncan Grisby]

Post by Bruce Visscher
Attached, please find a patch that applies to omniORB 4.1.5, a patch
that applies to omniORBpy 3.5. These files are primarily for the
OpenVMS(*) platform.

Thanks, Bruce!

[...]

Post by Bruce Visscher
I also made some changes in the way exceptions are thrown from the
omniORB library. Rather than having a macro that calls a function
that throws and exception, I modified the function to return the
exception and the macro to throw the result.

I have already made a similar change to the 4.2 branch (trunk in svn).
Unfortunately, the change cannot be made in 4.1.x because it breaks
binary compatibility. What I've done instead is to make it optional in
4.1, and enabled it by default only for VMS. That will only break binary
compatibility in VMS, so maybe that's ok?

I've applied the rest of your tweaks, with a few small changes, to the
4.1 branch. I'm planning to release 4.1.6 within the next couple of
weeks, so please can you check the current svn contents to ensure
they're ok?

Post by Bruce Visscher
I was also going to send an updated etc/openvms.zip file but gmail
brokenly thinks that zip files are executable files so it won't let
me. I will have to find another way.

If you're not able to email it, I can arrange somewhere for you to FTP
it.

Thanks,

Duncan.

[Bruce Visscher]

Hi Duncan,

Post by Duncan Grisby

Post by Bruce Visscher
Attached, please find a patch that applies to omniORB 4.1.5, a patch
that applies to omniORBpy 3.5. ?These files are primarily for the
OpenVMS(*) platform.

Thanks, Bruce!
[...]

Post by Bruce Visscher
I also made some changes in the way exceptions are thrown from the
omniORB library. ?Rather than having a macro that calls a function
that throws and exception, I modified the function to return the
exception and the macro to throw the result.

I have already made a similar change to the 4.2 branch (trunk in svn).
Unfortunately, the change cannot be made in 4.1.x because it breaks
binary compatibility. What I've done instead is to make it optional in
4.1, and enabled it by default only for VMS. That will only break binary
compatibility in VMS, so maybe that's ok?
I've applied the rest of your tweaks, with a few small changes, to the
4.1 branch. I'm planning to release 4.1.6 within the next couple of
weeks, so please can you check the current svn contents to ensure
they're ok?

Thanks, that's fine with me. I will check it as soon as I can.

Post by Duncan Grisby

Post by Bruce Visscher
I was also going to send an updated etc/openvms.zip file but gmail
brokenly thinks that zip files are executable files so it won't let
me. ?I will have to find another way.

If you're not able to email it, I can arrange somewhere for you to FTP
it.

Please see the attached patch to etc/openvms.zip. To tell you the
truth, the vms build needs work. I have been working on an alternate
build that uses GNV which is analogous to cygwin for VMS. If I could
complete that then we could remove openvms.zip. I have gotten as far
as a working omnidl and omniNames so it might actually be feasible.

As yet another alternative, the direction I have recently taken in
building application code is to use a non-recursive makefile system
(google "recursive make considered harmful"). I find this much more
robust and easier to maintain. Would this be worth pursuing for
omniORB? Unfortunately, I suppose it doesn't play well with
autoconfig tools - at least not at the moment.

Bruce
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniORB-4.1.5.vms.build.diff
Type: application/octet-stream
Size: 101685 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110621/458dc514/omniORB-4.1.5.vms.build-0001.obj

[Duncan Grisby]

On Tue, 2011-06-21 at 09:13 -0400, Bruce Visscher wrote:

[...]

Post by Bruce Visscher
As yet another alternative, the direction I have recently taken in
building application code is to use a non-recursive makefile system
(google "recursive make considered harmful"). I find this much more
robust and easier to maintain. Would this be worth pursuing for
omniORB? Unfortunately, I suppose it doesn't play well with
autoconfig tools - at least not at the moment.

omniORB's make system is over complex and full of historical baggage.
I'd be happy to replace it all with something simpler, but it's hard to
do that given all the weird and wonderful platforms that must be
supported. It's just not something that I've had time for, and it's not
really a priority for most platforms because the current system works
ok.

I don't think there's any inherent reason why autoconf can't be used
with a flat makefile.

Cheers,

Duncan.