On 03/22/05 17:18:37, Ben Reser wrote:
> On Tue, Mar 22, 2005 at 05:04:21PM -0600, Ben Collins-Sussman wrote:
> > 1. What is the state of our SWIG support as we move into 1.2? Which
> > versions do we want to support, which versions do we not want to
> > support?
>
> SWIG 1.3.24 and pregenerate source in the 1.2.x tarballs.. Let's use
> this as an opportunity to clean up cruft. We're going to be doing betas
> for 1.2.x so we have a great chance to fix any problems before we do a
> full release.
I agree with this as well. I would actually encourage dependence on 1.3.25
(which has yet to be released). We are close to a 1.3.25 release (a couple
weeks maybe), and there are a few nice improvements in 1.3.25.
We recently added the -external-runtime option to SWIG so that code like
swigutil_py.c does not need to include files directly from a SWIG install.
If you use the -export-runtime argument, you won't need that ifdef that is
currently inside swigutil_py.c to include swiglabels.swg.
See the latest CVS version of Modules.html for how this works.
http://cvs.sourceforge.net/viewcvs.py/swig/SWIG/Doc/Manual/Modules.html?view=markup
The short reason we changed to this option was so that external code was
not directly including header files from the Lib/ directory and didn't need
to know the file names and such. For the thread that spawned this idea, see
http://mailman.cs.uchicago.edu/pipermail/swig/2005-February/011450.html
and especially
http://mailman.cs.uchicago.edu/pipermail/swig/2005-February/011455.html
This thread might also be of interest
http://mailman.cs.uchicago.edu/pipermail/swig/2005-February/011573.html
Secondly, to support building subversion without SWIG installed, you can
look for a folder named SWIG or SWIG-version inside the subversion
directory, run ./configure && make, and then run SWIG/preinst-swig to
generate the wrappers (and run preinst-swig to create the swigpyrun.h file).
Combining the -export-runtime option with some makefile rules (and
supporting building the wrappers just from a SWIG sourcecode subdirectory),
you would be able to remove all those version hacks inside swigutil_py.c
(like including swiglabels.swg), and drop support for anything below
1.3.25. This won't hurt too much because SWIG won't even need to be
installed.
John
PS: If you recall the long discussion about API of the runtime functions on
this list, SWIG introduced the SWIG_RUNTIME_VERSION define. In 1.3.25,
this version has been bumped to "2" instead of "1", but there has been no
API change. What happened was an internal memory layout change (some
linked lists were switched to arrays, speeding up initialization from
O(n^2) to O(n log n) along with some other changes). So you should not
need to concern yourself with the fact that the runtime version has
changed...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 28 02:55:33 2005