Max Bowsher wrote:
> ...
> However, this doesn't work on Cygwin, and making libsvn_swig_perl
> into a static library isn't a solution, because it needs to link to a
> shared libswigpl.
What is the actual error you get with the patch? libsvn_swig_perl shouldn't
have a link step since its a static library. And all the perl modules that
depend on it already link to libswigpl.
> Please, can we put Perl's current_pool back in libsvn_swig_perl?
>
> Otherwise, this interdependency is *really* going to mess up ever
> getting the perl bindings to work on Cygwin.
We can revert the change, but I'd like to know how the static library
solution fails on cygwin.
> Could you explain what the gains of the big bindings shakeup begun in
> r10233 are? I'm not familiar with the Windows build, so it's hard for
> me to understand what the motivation was.
The main motivation was to simplify the windows build. Putting the swig
runtime into the core modules allowed us to remove the clunky
gen_swig_runtime.py script and other apparatus for building the swig runtime
separately. Ben Reser also said it could help with multiple versions of perl
on the same machine (
http://www.contactor.se/~dast/svn/archive-2004-07/0451.shtml ).
r10233 moved the swig runtime into core modules on windows
r10236 got the same thing working on unix
r10374 reverted the effects of r10233 and r10236 on unix due to
incompatibilities
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 26 03:09:41 2004