You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2004/12/01 00:12:22 UTC
Re: [Patch] Update SWIG support
On Tue, Nov 30, 2004 at 02:27:21PM -0800, Ben Reser wrote:
> On Tue, Nov 30, 2004 at 04:47:04AM +0000, John Lenz wrote:
>...
> > As an added advantage to this, swig becomes a tool sort of like lex or
> > yacc. That is, some projects release the swig generated .c files with the
> > released tarball.
>...
> This would be nice. It would also diminish my disagreement with
> requiring 1.3.24. But I'm still not sure I'm in favor or requiring
> 1.3.24 even if this was implemented.
This would rock. Any developer that cares to build the SWIG bindings
from _source_control_ would need to upgrade to the latest SWIG.
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.
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.
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).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Patch] Update SWIG support
Posted by John Lenz <le...@cs.wisc.edu>.
On 12/03/04 00:34:28, John Lenz wrote:
> 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.
You could actually incorporate SWIG as part of the subversion build process
similar to the way apr and neon can be compiled from the build directory.
That is, if SWIG 1.3.24 is not installed, the developer could just download
SWIG and extract it into the subversion source directory. Subversion would
then run ./configure and make in the SWIG directory, and then use the
preinst-swig script during the wrapper build process. Since there is no
runtime dependence on anything swig and swig can be run to produce the
wrapper code without being installed, this will work fine. The releases
are tagged in the SWIG CVS, so you could check out the release that way as
well.
If you do this, the only issues would be those of regressions in 1.3.24 vs
1.3.21 since you wouldn't be forcing a new tool on developers.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Patch] Update SWIG support
Posted by John Lenz <le...@cs.wisc.edu>.
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
Re: [Patch] Update SWIG support
Posted by Ben Reser <be...@reser.org>.
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 <be...@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