On 11/30/04 08:57:15, Greg Hudson wrote:
> On Tue, 2004-11-30 at 03:42, Branko Čibej wrote:
> > John Lenz wrote:
> >
> > > <rant>If subversion is using a depreciated feature, then you should
> > > notify the SWIG developers.
>
> It was our best understanding that SWIG had adopted a totally insane
> position on the support library (that a module had to decide at build
> time whether to include the support library functions, and if a program
> wanted to use multiple libraries, precisely one of them needed to be
> built with the support library enabled, such that it becomes impossible
> to distribute binaries of swig-using modules), and that this issue had
> already been discussed on the swig list without changing your minds
> about it. See http://svn.haxx.se/dev/archive-2004-09/0873.shtml and the
> other messages in that thread.
Yeah, that was how it was for a while. We did that in an effort to
simplify, but it didn't work out so well.
At least subversion should fail to compile if swig > 1.3.22 is used, and
even 1.3.22 has a few issues.
>
> That said, if we all had more time, we would have put more effort into
> communicating about this issue. It sounds like the actual situation may
> be better than what we understood, perhaps due to a new feature of swig
> 1.3.24.
Perhaps I should have explained a little more. In 1.3.23, the type
information (which is what needs to be shared between modules) is now
shared by a global python variable rather than through C linkage. Think of
it like this... to share type information, we have one linked list of all
types SWIG knows about. This same linked list needs to be shared with all
the modules that might interact. For the longest time, we shared this
through C linkage (that is with an extern and such). Now, this linked list
is stored in a global python variable. Thus when a module loads, it first
looks up the global python variable called swig_runtime_data_type_pointer.
If that variable exists, it uses that as the linked list of types and adds
the types in its module to that global linked list. If the variable does
not exist, it creates a new linked list and creates the variable. This way
we are able to share runtime data between modules with no C linkage at all.
That is, removing support for libswigpy (which is where the linked list was
stored) does not actually impact the ability to build multiple modules.
There was a slight problem in 1.3.23, in that files that were not swig
modules but did use the type information needed to support this new way as
well. swigutil_py.c in subversion for example. In 1.3.24, you just
include the "runtime.swg" file, which does exactly what I described above
and allows the file to call TypeQuery.
>
> > > 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.
> >
> > If this patch requires 1.3.24, then sadly we can't use it as it stands
> > because there are lots of systems come with older versions.
>
> As John pointed out, we can start treating swig like we treat libtool
> and autoconf--a dependency only for those who check out Subversion from
> the repository or who make changes to the .i files, not for those who
> simply compile it from a tarball.
Yeah, it makes a bunch of people's lives a lot easier because they don't
need to make sure they are using a compatible version.
>
> > Note: I added the -DSWIG_TYPE_TABLE=subversion argument when
> > compiling swig generated module files.
>
> I'm a little surprised that this isn't a declaration in the .i files,
> rather than a compile-time option. But I don't totally understand all
> the issues involved, and I don't think it matters much for us. I don't
> think we expect modules from outside the tree to import our .i files.
Well, you can always stick %{ #define SWIG_TYPE_TABLE=subversion } into the .i
file...
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 20:26:53 2004