On 8/4/05, Daniel L. Rall <firstname.lastname@example.org> wrote:
> On Thu, 04 Aug 2005, David James wrote:
> > > > There are also more severe issues with Subversion's support for SWIG
> > > > 1.3.20 and 1.3.21, which have not yet been addressed. See <
> > > > http://svn.haxx.se/dev/archive-2005-08/0053.shtml >. For this reason,
> > > > I think it would be a good idea to encourage users to upgrade to newer
> > > > versions of SWIG, if they can.
> > > I agree with this, though. I think we ought to raise our minimum version to
> > > 1.3.24.
> > Great! If we are moving to SWIG 1.3.24, there is no need to discuss
> > the problems with SWIG 1.3.21 in the INSTALL file. Would you be happy
> > with my patch if I instead deleted the information on older versions
> > of SWIG? I can also patch the swig.m4 file to disallow SWIG 1.3.19
> > through 1.3.21, if you think this is a good idea.
> > On the python-bindings-improvements branch, I had to copy and paste a
> > large section of code from SWIG in order to support new SWIG features
> > on old SWIG versions, such as 1.3.19. If we forced users to upgrade to
> > SWIG 1.3.24, this code would not be necessary.
> This sounds like a reasonable requirement for the 1.3.x line.
OK, great! I've implemented and documented this new requirement in
r15620 on the python-bindings-improvements branch. All developers who
compile the bindings from trunk will now need SWIG 1.3.24 or better.
Further, if you run autogen.sh in release mode, it will generate
standalone "C" files for all of the SWIG files, so that SWIG will not
be a dependency. In order to get this working, I had to run the Perl
"vtable wrapper code generator" from inside autogen.sh, so that the
vtable wrapper code would be included in the standalone "C" files. (I
reimplemented the vtable wrapper code generator in Python so that
users of all the bindings could benefit without adding Perl as a
See the change at:
Please review the change and let me know if you have any feedback.
This change in particular will need to be reviewed carefully because
it makes big changes to our build process.
David James -- http://www.cs.toronto.edu/~james
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Aug 8 13:43:51 2005