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

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

-- 
Nobu Nakada