On 11/30/04 20:54:24, Ben Reser wrote:
> 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.
Absolutely not. If you use 1.3.24, SWIG does NOT need to be installed AT
ALL to run the bindings. Up until 1.3.23, SWIG needed to be installed AND
needed to match the version that subversion was compiled with, but the way
the runtime system works was completely rewritten for 1.3.23.
> 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.
That has changed. It is one of the huge changes of 1.3.23. Up until
1.3.23, there were tons of problems with versions not working and this and
that, but with the new runtime system in 1.3.23, there is no version
problem. Actually, now it should be possible to build a module with 1.3.23
and a module with 1.3.24 and a module with any future release, and they
should all will able to work together.
And secondly, the only people that would need to upgrade to SWIG are
developers of subversion. SWIG can even be run from the source directory
without installing it. That is, you don't even need to install it. If you
download SWIG, you should be able to do ./configure && make, and then in
subversion run ./configure --with-swig=~/path/to/SWIG/preinst-swig.
preinst-swig is a script that runs swig from the source directory. (It
sets up the right paths for the data files that would normally be located
in /usr/share/...) Since SWIG no longer has any runtime libraries, a SWIG
install just consists of the swig binary and the associated data files.
You don't even need to have perl installed to generate perl wrappers.
>
> 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.
What issue is that? I tried searching on google, but didn't really see
anything. If I know what the issue is, I can test and see if it is fixed
for perl, and if not, I will fix it.
>
> 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 don't really understand what you're saying here. Sure, you could just
stay around forever at 1.3.21, but then you won't get advances in SWIG.
Granted, almost all new features in SWIG are improved support for various C
++ features. 1.3.24 has way better support for directors (so called, cross
language polymorphism), better support for templates, better support for
the std::vector,std::list,std::map,etc. Thus subversion probably doesn't
see many new benifits. But various bugs are being fixed as well. 1.3.24
simplifies the way this stuff works and makes people's lives who distribute
subversion easier. The visible change to the end users is they can forget
everything they ever knew about SWIG.
>
> 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.
Both SWIG and SWIG generated code works on Windows, and a few SWIG
developers only develop on Windows. Before a release, our test suite is
run on both linux and windows. It works with cygwin or Visual Studio.
Secondly, all compiler dependencies are inserted into the wrapper file,
with #ifdef __GNU_C or whatever. Thus if you generate a wrapper on linux,
it will compile fine on windows and vice versa. Or if you generate the
wrapper on windows, it will compile with suncc on Solaris. Again, since
there is no longer a runtime library, the only output from SWIG is the
wrapper file.
>
> > 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.
Well, SWIG has a very extensive test suite (check the Examples/test-suite
directory), so there are not many regressions. There might be issues that
are not covered by the test suite, but every time a bug or whatever is
found, a entry in the test suite is added. As such, I am willing to help
on the SWIG side. Perhaps you can upgrade to 1.3.24 on a development
branch of subversion, and if any problems come up, I can fix them and then
add the problem into the test suite so it doesn't happen again. If we
increase the communication between the projects, this shouldn't be a
problem.
>
> 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.
Well, since the patch only really changes how stuff is built, it would be
possible to support both 1.3.21 and the new 1.3.24. If you notice, most of
the patch is removal of code that isn't needed anymore. Perhaps it would
be a good idea to start building a test suite to test the subversion python
bindings. Even if you keep using the same version of SWIG, perhaps
something else changed that broke the python API for some reason.
SWIG 1.3 is a development branch, and so occasionally things will break.
Once we reach 2.0, these issues shouldn't come up. (don't ask for an
estimate, it will release when it's ready :) The FUTURE file in the SWIG
source describes the feature goals for a 2.0 release)
I can say right now that the fundamental way that runtime support works
will not be changing again. The new scheme in 1.3.23 is WAY easier for
both SWIG to support and for SWIG users to use, and does everything the old
version did.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 3 07:35:51 2004