Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native

On Sun, Jun 27, 2004 at 11:16:16PM -0400, Russell Yanofsky wrote:
> We're not using perl internals, we're just using a handful of public, well
> documented API's that perl provides for extension writers. The API's don't
> require us to use weird compiler flags, so we shouldn't use them.

They're still internals. There are no guarantees that the interfaces
stay the same, and often do change. They're documented in a man page
called "perlguts".

> > Say Perl was built with -D_FILE_OFFSET_BITS=64, then off_t will be
> > 64-bits long. But the default is to use 32-bit off_t's. So when we
> > give Perl an off_t that is 32-bits and it is expecting a 64-bit off_t
> > we'll get a segfault...
>
> I don't think we should be using -D_FILE_OFFSET_BITS either, see
> http://www.contactor.se/~dast/svn/archive-2004-01/0471.shtml

We're not choosing to use it. The person who built Perl is. Right or
wrong it's there. We could filter it out. But I don't think that's
right. Right now we don't happen to be using any function calls that
not having it is going to impact. But if we ever do start using
PerlIO_tell, PerlIO_seek, etc... we will be impacted by not pulling it
in. IMHO it is the entirely wrong to have a build system that'll break
just because we decided to seek...

> Maybe it is neccessary for Perl to emulate fork under windows, but we're not
> building Perl. We're building the subversion bindings, which do not work
> with PERL_IMPLICIT_SYS. PERL_IMPLICIT_SYS causes the perl headers to #define
> bunch of posix and standard C functions, which interferes with the Microsoft
> headers included by APR.

This isn't anything unique to Windows. Perl defines lots of function
names that unfortunately clash with standard names. Refer to the past
dicussion about warnings from the build of the perl bindings.

> Options like -DPERL_IMPLICIT_SYS and -D_FILE_OFFSET_BITS=64 are pretty
> invasive. I can't imagine that perl would require extensions to be built
> with them.

They come form $Config{ccflags} which MakeMaker uses. So as much as you
can't imagine it, they are the proper flags for building extensions to
Perl.

We can simply ignore them on Windows. But I seriously think this is the
wrong thing to do.

> On windows, the subversion libraries are currently static so you need to
> link against the libraries they depend on.

I thought they were going to be DLLs? It seems really silly to be doing
statics. We end up with the libs built into the command line client,
the svnadmin command, the python bindings, the perl bindings, and the
java bindings. What a horrible overkill.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org