"Ben Reser" <ben@reser.org> wrote in message
news:20040628062134.GC3450@synapse.brain.org...
> 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.
Whether they change or not is irrelevant. I'm only saying that because they are
public interfaces used by lots of external projects, they shouldn't require all
code that interacts with them to be built with weird compiler options.
> They're documented in a man page
> called "perlguts".
Them perl people be so clever.
> > > 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.
I'm not saying we should filter the options in ccopts, I'm saying we should
ignore them entirely.
> 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...
If adding a call to seek breaks something, then it's not the build system's
fault, it's perl's fault for redefining standard types and then using those
messed up types in its public interface. The correct solution to that problem,
should it ever occur, would be to isolate calls to the perl IO calls in a single
source file, build that one source file with perl ccopts, and write a long
comment at the top of the source file saying nasty things about perl developers.
IMHO, it is entirely wrong that builds of the subversion bindings will only work
under certain configurations of perl. There is no reasons for the bindings to
break just because perl was built with IMPLICIT_SYS or OFFSET_BITS=64 or some
other option that is totally unrelated to their functioning.
> > 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.
They don't /unfortunately/ clash with standard names, they /intentionally/ clash
with standard names to implement functionality that has nothing to do with the
subversion 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.
Isn't it our makefile.pl script that is putting perl ccopts there?
> So as much as you
> can't imagine it, they are the proper flags for building extensions to
> Perl.
I'll admit that the perl way of doing things is pretty foreign to me.
> We can simply ignore them on Windows. But I seriously think this is the
> wrong thing to do.
Well, you know what the options are for getting makefile.pl to work on windows.
You can go about it however you like. I just think it would be better to
manually specify compiler options appropriate for the subversion bindings
instead of copying the options used to build perl.
> > 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.
Agreed. This issue (#1627) was solved back in January, but it was put on hold (I
think) because of the subversion 1.0 release.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 28 20:23:06 2004