[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Next Release: Perl Bindings Fixed for Win32?

From: Ben Reser <ben_at_reser.org>
Date: 2004-04-09 20:43:01 CEST

On Fri, Apr 09, 2004 at 02:00:30PM -0400, Mark Watts wrote:
> I would like to respectfully ask the Subversion developers consider fixing
> whatever prevents the Perl bindings from being build on Win32 platforms for
> the next release?

I'd love to do this. I have 1 copy of Windows. But I don't have a
development environment for it and it runs under vmware which means it
is absurdly slow. So I won't do this myself.

> Given that it will be some time, perhaps years, before Subversion will be
> able to provide some of these features itself and that some of these
> features are already available in SVK I would like to be able to use SVK.
> However, I can't because the Perl bindings don't compile on Windows.

I'm really not entirely sure here. I've offered on multiple ocassions
to work with people to get this figured out. Nobody has really taken me
up on this.

Perl's build system is very Unix centric. Currently, a perl script runs
that builds a Makefile that is suitable for the systems make. There is
a new system being built (for perl) that does everything from the perl
script and avoids the dependency on make. However, it's not complete,
really can't handle building C files yet, and isn't included in Perl.
Which means if I tried to switch to using it, I'd inconvience all the
Unix installations just to try and make things easier for Windows.

Someone asked a while back if we could find a way to build the Perl
bindings without make. I said that it was simply easier for them to
install make than for me to re-engineer the entire perl build system.

Since then it has come to my attention that Microsoft development tools
ship with "nmake" which if your Perl install is properly configured
the Makefile.PL should be able to build a makefile that will work with
nmake.

> I have asked on the SVK mailing list and one of the developers graciously
> reported that he spent about 6 hours trying to get them working. And he
> also indicated that he was one of about 3 people who had tried to get them
> working. Which begs the question: What about the Perl bindings is it that
> causes them to work just fine on Linux and are so totally broken on Windows.

This is really frustrating to hear. None of these people have reported
the problems they experienced. None of these people have tried to work
with me.

> Please understand: I realize I am not a SVN developer, just a user, and that
> as such I have very little input into what the priorities are. I just think
> that the feature set available in SVK is so compelling that not having them
> available on Windows is a big deal.
>
> I suspect that there are other Windows Subversion users out there that would
> also find a huge benefit in using SVK.

I agree. I want the Perl bindings to build and work on Windows. But I
can't do it alone. We've had problems with other platforms (OS X) in
the past that we've fixed. I don't see dealing with this as any
different than other platforms.

Ultimately, this hasn't happened because someone with the platform and
the necessary tools hasn't made it a priority to make it work. I'll
help anyway I can. But unless someone decides to buy me the necessary
Windows software and pay me for my time I'm not going to do it myself.
I suspect clkao is in a similar position.

So once again, I'm making myself available. Drop me an email, catch me
on IRC, etc... I'll do what I can to help.

-- 
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
Received on Fri Apr 9 20:43:14 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.