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

Swig 1.3.22 and the missing runtime libraries

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-09-26 18:59:26 CEST

The Swig 1.3.22 release announcement includes

http://mailman.cs.uchicago.edu/pipermail/swig/2004-September/010428.html

  "- SWIG runtime library support deprecation."

In fact it has been removed rather than deprecated, CHANGES.current
includes

   "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

http://mailman.cs.uchicago.edu/pipermail/swig/2004-September/010412.html

   "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

http://mailman.cs.uchicago.edu/pipermail/swig/2004-August/010368.html

   "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
imagination.

Index: Makefile.in
===================================================================
--- Makefile.in (revision 11132)
+++ Makefile.in (working copy)
@@ -593,3 +593,18 @@
 
 clean-swig-pl: $(SWIG_PL_DIR)/native/Makefile
         cd $(SWIG_PL_DIR)/native; $(MAKE) clean
+
+swigrun.i:
+ echo "%module swigrun" > $@
+
+swigrunpy.c: swigrun.i
+ $(SWIG) -runtime -python -o $@ $<
+
+swigrunpy.lo: swigrunpy.c
+ $(COMPILE_PY_WRAPPER) $<
+
+libswigpy.la: swigrunpy.lo
+ $(LINK) -o $@ $<
+
+install-libswigpy.la: libswigpy.la
+ $(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

http://mailman.cs.uchicago.edu/pipermail/swig/2004-August/010370.html

  "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
  problem."

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 26 18:59:47 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.