[PATCH] Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings

As promised, I attached a patch to eliminate the compile problems
where APR and ruby headers need to combined. In my case, the usecase
is that I want to compile a ruby extention for APR based software.

The log:

[[[
Resolve possible type definition conflicts by defining types in
the rb_ namespace instead of defining POSIX type names.

* configure.in: Check for the availability of pid_t, gid_t and uid_t.

* defines.h: Remove pid_t typedef.

* ruby.h: Define rb_pid_t, rb_gid_t and rb_uid_t in accordance with
  the available system types.

* process.c: Change instances of pid_t and gid_t to their rb_*
  counterparts.

* ext/pty/pty.c: Change pid_t to rb_pid_t.

* vms/config.h: Define HAVE_{P,G,U}ID_T to 1.

* win32/Makefile.sub: Define HAVE_{P,G,U}ID_T to 0.

* win32/win32.c: Change pid_t to rb_pid_t.

* wince/Makefile.sub: Define HAVE_{P,G,U}ID_T to 0.

* wince/sys/types.h: Remove definitions of {p,g,u}id_t.

]]]


Note that I submitted a patch to APR too which should resolve future
problems with other software. I'd appreciate it if you would accept (a
variant of) this patch into the ruby tree.

bye,


Erik.

On 4/26/05, Erik Huelsmann <[e-mail]> wrote:
> 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.
>