On Tue, Nov 30, 2004 at 04:12:22PM -0800, Greg Stein wrote:
> This would rock. Any developer that cares to build the SWIG bindings
> from _source_control_ would need to upgrade to the latest SWIG.
I'm not a big fan of shoving the latest versions of tools down everyones
throats. The thing here is that the people developing bindings are not
so hot on the idea... Probably because they don't have to deal with
packaging a version of SWIG for all their machines because the version
available from their chosen OS/distro vendor isn't good enough anymore.
> Developers who use the tarballs or other releases could care less. Or
> end users or developers who give a rats ass about the bindings can
> just do nothing.
Huh? What developer is working off a tarball. End users sure. But
nobody actively developing on SWIG bindings is doing this.
> Hunh. Note that all of our releases would now support the bindings. No
> need for SWIG to be installed at all. That greatly increases our
> coverage of users who would have access to the bindings. That rocks.
To be honest I'm sceptical of this claim. Last time I remember looking
at this stuff the SWIG Perl bindings were highly dependent upon version
of SWIG being used to generate code being built for the version of Perl
being used. Unless they've fixed this (which isn't very likely given
the way Perl changes their internals), then Perl isn't likely to benefit
from this change. Which means requiring 1.3.24 forces all the Perl
people to upgrade the SWIG on their machines.
Which is part of the problem Greg Hudson was talking about earlier.
They're claiming the issue of symbols is fixed, but he's very specific
about that this fix has to do with Python. He never once says what the
status of the Perl support is.
Additionally, all of our releases support bindings already. This would
just remove a dependency. But it would remove a multitude of problems
that prevent the bindings from being built and installed by default.
This is not some magic silver bullet that fixes the number of people
that can use the bindings. Yes it helps. But we don't even build the
bindings by default even if SWIG is available. So I doubt it would
increase the number of people who have the bindings available.
I also have to wonder how this interacts with our Windows source
packaging. SWIG handles some platform issues for us by generating
different code on Windows. However, our Windows source packaging isn't
generated on Windows, it's generated on the same *nix system that build
the tarball. So there's the possiblity this would just make Windows
support for the bindings a little bit different and odd.
> I'm a big +1 on switching to 1.3.24 as soon as it gets released, and
> then disable compatibility with all previous SWIG releases. It will
> simplify a great many things and should not really impact people much
> at all (unless you care about them and you build from source control).
I'm much more cautious about this. As Justin points out SWIG has a
habit of messing things up with their releases. I would really
despise doing a release that unnecessarily breaks the bindings for
everyone. In the past we've always had a solution. If 1.3.24 has some
issue lurking in it we probably won't know about it until we release the
bindings (hardly anyone tests the bindings from our trunk) and then
there will be no fallback plan except to tell people to use older
versions of Subversion that still work.
Let's not get in too big of a hurry to make drastic changes to our
dependencies without:
a) First seeing if 1.3.24 actually delivers.
b) That it delivers for everyone not just one language.
c) That it delivers for not just *nix systems but for Windows too.
d) That it delivers without hosing something else.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 1 03:55:30 2004