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

> > > Ruby is just using AC_TYPE_UID_T.  So, using typedef for them,
> > > like as apr.h, means conflicts to all of autoconfiscated
> > > softwares.  I think apr.h should #undef before typedef.
> >
> > Ah, but it only does that on Windows, not on POSIX platforms. On POSIX
> 
> Not only on Windows, any platforms which don't have [ugp]id_t.

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

> > I intend to provide a patch for Ruby which defines a rb_pid_t (and
> > friends) for all platforms. (If you want it to be differently named:
> > that's fine ofcourse.) On windows it will be defined to int, on other
> > platforms, it will be defined to AC_TYPE_PID_T.
> 
> rb_pid_t sounds good enough, and ruby itself would be too,

Great! I hope CVS comes up soon then: i can start the work.

> but
> what about extension libraries using those types?

Well, I have no idea what promisses you made to extention library
implementors.. But if you can choose, well, I'd encourage them to use
rb_pid_t too.

bye,


Erik.