On Mon, August 1, 2005 11:12 pm, David James said:
> The problem: SWIG 1.3.21 isn't that great at TypeQuery lookups. For
> example, if you ask for "svn_fs_root_t *", SWIG_TypeQuery returns
> NULL. When you pass the NULL pointer into SWIG_NewPointerObj, it
> segfaults.
Thats correct. The older TypeQuerys had some problems...
>
> Do other people also notice this problem? This looks like it's a bug
> in SWIG, and it'll be difficult to work around. If other people also
> notice this bug, I'd suggest we take one of three options:
> 1) Find some way to make Subversion and SWIG 1.3.20 and SWIG 1.3.21's
> runtime lookup system work well together.
The biggest problem with this is that before 1.3.23 or so, the runtime
type stuff was a huge mess. It was using tons of hacks, the code was very
difficult to follow, etc. With 1.3.25 for sure, the run time type stuff,
while it didn't change much in functionality, got a lot easier to
understand and the code is much more straight forward.
Thus, trying to fix the 1.3.20 and 1.3.21 TypeQuery would be a lot of
work. (well, it might be a small fix, but the problem is figuring out why
TypeQuery isn't searching all the types...)
> 2) Avoid runtime type lookups altogether. Redesign Subversion's SWIG
> library to use compile-time lookups instead.
I'm not all that familiar with the subversion sources and how difficult it
would be, but I would say this would be the best solution. Now if it can
be done with minimal support....?
> 3) Drop support for SWIG 1.3.20 and 1.3.21.
The other solution is what I have been talking about for a while now... as
of 1.3.25, SWIG is a build time only tool, and the output from SWIG can be
compiled on any computer. Think lex and yacc... SWIG now functions just
like them.
You can read the archives for some discussion on it, but the idea is that
only the developers would need to have SWIG installed... you could include
the build output from SWIG directly in the released tarballs. I find this
idea similar to the reason neon and apr are included in the tarballs.
If you stick the output .cxx files from SWIG into the svn repository, then
only when a header or .i file changes will SWIG get invoked. I attempted
to do this at one point, but the Makefile and python scripts to generate
Makefiles were confusing so I didn't go that deep into it.
The other advantage is that the developers can stay current with SWIG
releases, geting all the bug fixes and such...
> P.S. Before testing with SWIG 1.3.21, be careful to delete all
> Python/SWIG-related files so that you don't accidentally test the
> wrong version of SWIG. The 'make clean' rule in Subversion does not do
> the job, because it does not delete Python/SWIG related files
> properly.
>
> Here is the build process I used to build and install SWIG:
> ./autogen.sh && ./configure --enable-static && make && make install &&
> make runtime && make install-runtime
>
> The "--enable-static" flag and the runtime installation targets are
> essential with early versions of SWIG, but are not necessary with SWIG
> 1.3.24 and up.
Yeah, that was one small piece of the mess of that runtime stuff....
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 5 06:06:37 2005