Re: [Hamlib-developer] port_t and OS X.... (API change proposal)

[Stephane F. <f8...@fr...>]

On Wed, Mar 23, 2005 at 05:10:31PM -0600, Marv wrote:
> Stephane Fillod said:
> > Marv wrote:
> > >Rob Frohne wrote:
> > >>I'm running into a problem with OS X, possibly also the reason RPC
> > >>doesn't compile on OS X as well.  The problem is that port_t is already
> > >>defined under OS X, in port.h, which is included with Apple's
> > >><AppKit/AppKit.h> and it is redefined in rig.h.  What can we do about
> > >>this?
> > 
> > This is a known problem of Hamlib with C++ under Mac OS X.
>  
>  Are there any plans to solve this?

Yes, no solution other than move away from port_t. To ease application
support, we have to provide an overlap. So I propose that the release
1.2.4 has port_t renamed to hamlib_port_t, but still retains support
for now deprecated port_t with something like this in rig.h:

#if !defined(__MACOSX__) || !defined(__cplusplus)
typedef hamlib_port_t port_t;
#endif

What you all think about it?


> > >I got it working by doing a quick and dirty substitution from port_t to
> > >hamlib_port_t.  The rpgcen problem is with rpcsvcdirty, right?  If so, I
> > >just removed the extern definition from the two generated .c files for
> > >rpcrig and rpcrot and it compiled.  Everything appears to work for me
> > >but it was a couple months ago and my goal was a quick test, not
> > >something that could be folded back into the source code.
> > 
> > What's the problem with the rpc backends?  Since it's not clear to me
> > and I cannot test, maybe you already have a solution or a patch?
>  
>  A reference to an external rpcsvcdirty is generated by rpcgen but 
>  isn't present in librpcsvc.  I have a trivial patch I can send out this
>  weekend.

Yes, please send your patch for inclusion.

Thanks
Stephane