[omniORB] Patch for OpenVMS

[Bruce Visscher]

Hi Duncan,

On Mon, Jun 20, 2011 at 6:15 PM, Duncan Grisby <duncan at grisby.org> wrote:
>
> On Thu, 2011-06-09 at 09:04 -0400, Bruce Visscher wrote:
>
> > 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!
>
> [...]
> > 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.

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