John Lenz wrote:
> 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.
I guess it all depends how far we really are from branching 1.2.
I agree entirely that migrating to not requiring SWIG at end-user build-time
is the way to go - I'm just not sure that so close to branching is the right
time to move.
> 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
Typo? s/export-runtime/external-runtime/ ?
> 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
Thanks for the tip! Useful.
> 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).
In the interests of keeping the size of our source tarball down, I'd rather
require that the release manager have swig installed, and just include the
pregenerated files in the final tarball.
> 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.
A very attractive thing to do, yes.
> 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...
Thanks.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 28 12:18:22 2005