The Swig 1.3.22 release announcement includes
"- SWIG runtime library support deprecation."
In fact it has been removed rather than deprecated, CHANGES.current
"The deprecated runtime library build has been removed"
This breaks the build of Subversion's Python bindings, and probably
the Perl bindings as well. The Swig developers appear to expect us to
build the runtime ourselves
"I'd certainly agree that you drop support for the runtime packages
and just modify subversion to build the runtime itself."
When told that the 1.3.21 release did not build the runtime libraries
correctly the response was
"This is no longer a problem as far as SWIG is concerned as the
runtime libraries are no longer built when installing SWIG. If you
want the runtime library you can build it yourself, see the
docs. So you now have complete control over how you build it and
thus the choice as to whether or not you declare the
dependencies. You can use libtool, cmake or hand crafted Makefiles,
take your pick."
Amazing! Perhaps we should follow their lead and and not build the
Subversion bindings either, and instead claim that users of the
bindings are responsible for building them :-/
I see from r10233, r10236 and r10374 there was a previous attempt to
get Subversion to build the runtime. From a brief look I think this
was attempting a static runtime build rather than a dynamic one, I
don't know if the problems that arose can be solved or whether that
might cause problems for users of the Subversion bindings if they also
wanted to use some other library's Swig bindings.
While trying to understand the problem I created this hack to make
1.3.22 look like 1.3.21, but it's not a solution by any stretch of the
--- Makefile.in (revision 11132)
+++ Makefile.in (working copy)
@@ -593,3 +593,18 @@
cd $(SWIG_PL_DIR)/native; $(MAKE) clean
+ echo "%module swigrun" > $@
+ $(SWIG) -runtime -python -o $@ $<
+ $(COMPILE_PY_WRAPPER) $<
+ $(LINK) -o $@ $<
+ $(INSTALL_LIB) $< $(SWIG_LIBSWIG_DIR)/..
In the end I don't really care about Subversion's bindings as I barely
use them, however someone who does care probably ought to address this
problem--even if only by attempting to persuade the Swig developers to
support building the runtime. They appear to be amenable to the idea
"We'd certainly accept a patch for Unix builds to link against, say
libtcl. It would indeed need to be optional. Previous attempts to
turn this on for all Unix builds did not work, I recall OSX being a
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Sep 26 18:59:47 2004