Hi. I am a swig developer and I also use subversion. In the 1.3.23
release, we completely removed the ability to link against the runtime
library. (The runtime library has been depreciated for over a year...)
A couple of points
1) subversion has been unusable with SWIG since 1.3.22 or so, since it uses
a depreciated feature (some hacks have been made around this, but not to my
liking). <rant>If subversion is using a depreciated feature, then you
should notify the SWIG developers. If the new feature which is supposed to
replace the depreciated feature does not work for some reason, then the new
feature needs to be fixed or the old un-depreciated. It's frustrating when
users ask on the swig mailing lists why subversion doesn't work.</rant>
2) The patch I attach here requires swig 1.3.24, which is not yet released.
(Although, we are planning on a release sometime this week). On the other
hand, the runtime dependency on swig is completely gone. NO libswigpy is
used anymore. After this patch, users of the python bindings do not need
swig installed.
As an added advantage to this, swig becomes a tool sort of like lex or
yacc. That is, some projects release the swig generated .c files with the
released tarball. Then someone who downloads say subversion-1.0.9 source
does not even need swig installed to compile subversion, since the .c files
are already provided. The only people who need swig are those that change
the .i file or someone building from the repository. Thus requiring 1.3.24
or higher swig version is no longer that much of a problem.
This patch does not implement the above feature, because I am not that
knowledgeable about how the build works and how released tarballs are
built... the rule to build the tarball has to depend on the generated .c
files, and then include them.
--------------------------------------------------------------
Here is some extra info about the details of a change I made
Note: I added the -DSWIG_TYPE_TABLE=subversion argument when compiling swig
generated module files. This tells the module that the type table it
should be looking in for its types is named subversion. Since each module
is compiled with the same SWIG_TYPE_TABLE, all the modules look in the
subversion table for their types. This protects other swig modules from
stepping on subversion symbols and types. If no SWIG_TYPE_TABLE is passed,
then types are stuck and looked up in the default type table, and other
loaded swig modules from some other project might clash...
1) This allows for separation of the type table between two separate
projects, so that say another project using swig can compile with -
DSWIG_TYPE_TABLE=myproj and then if both the subversion bindings and myproj
bindings are loaded at the same time, they won't step on each other.
Notice, in the old way of linking against the runtime library, this could
be a problem and there was no way around it.
2) The only problem with this approach is that any other swig modules built
outside the tree that %import .i files from inside subversion also need to
be compiled with -DSWIG_TYPE_TABLE=subversion. If that's the case, then
you could probably just not define SWIG_TYPE_TABLE and allow the default
type table to be used. Then external modules don't need to worry about
adding SWIG_TYPE_TABLE.
Note, this SWIG_TYPE_TABLE is defined when the .c file is compiled... While
running swig, we don't care which type table it is going to be in, and
indeed, you could compile the swig generated .c file a couple of ways with
different -DSWIG_TYPE_TABLE (not sure why, but you can...)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 30 05:48:21 2004