Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings

On 4/26/05, [e-mail] <[e-mail]> wrote:
> Hi,
> 
> At Tue, 26 Apr 2005 05:05:02 +0900,
> Erik Huelsmann wrote in [ruby-core:04794]:
> > > > platforms, it uses what's there. Just like Ruby. I don't think it's a
> > > > solution for ruby to require that APR uses #undef before the typedef:
> > > > that would require a change to *all* software with which Ruby is meant
> > > > to be compiled on windows. Not a pretty solution.
> > >
> > > And APR requires a change to all autoconfiscated softwares.
> >
> > Actually, Ruby uses a #define (as a result from the old use of
> > AC_CHECK_TYPE, probably), but the autoconf manual itself says that
> > AC_CHECK_TYPE with 2 arguments is flawed because it uses #define
> > instead of typedef.
> 
> What `flaw'?  Using #define instead of typedef itself?  I don't
> consider it a flaw.  typedef has its own problem, too.  What's
> the reason why you claim that #define is wrong?

*I* don't call it a flaw, the Autoconf manual does. It has called it a
flaw ever since Autoconf 2.13 (see the section on AC_CHECK_TYPE and
its 2 variants).

I don't think using '#define' more wrong than it is to use 'typedef':
In both cases you're creating a type which is also defined in a
published standard. That's wrong, since there's no guarantee that your
software won't be combined (using SWIG for example) with software
which is going to try to do the same. That's bound to lead to the
conflict we're seeing.

> > > > I think neither APR nor Ruby should be 'messing' with types defined by
> > > > POSIX. I'm preparing a patch for APR to stop doing this.
> > >
> > > Agreed.  typedef which can'te be redefined nor detected at
> > > compile time shouldn't, at least.
> >
> > Right, but since the Subversion Ruby bindings have to include both
> > ruby.h and apr.h (which should both use typedef for pid_t, if they
> > were to define it with the 'new' autoconf).  So you see the conflict
> > growing fast: apr can't itself rely on ruby.h being included, nor can
> > ruby.h rely on apr.h being included, yet both systems try to define
> > pid_t.
> 
> So macro would be better than typedef in that sense.  Anyhow,
> the macro is mandatory to compile them together.
> 
> Maybe best ways were that all programs using pid_t have:
> 
>  #ifndef pid_t
>  typedef int pid_t;
>  #define pid_t pid_t
>  #endif

In this case you're depending on other software being written adhering
to certain standards. If you do:

#if HAVE_PID_T
typedef pid_t rb_pid_t;
#else
typedef int rb_pid_t;
#endif

You're not depending on any software defining or redefining anything.
So, I'd say that's the preferred way to do it.

All this said, I downloaded a ruby snapshot yesterday (given that the
CVS service is still down). There are very few ruby internals which
refer to the pid_t type, so it will be a minimal patch to define an
rb_pid_t.

bye,


Erik.