On Tue, Nov 30, 2004 at 04:47:04AM +0000, John Lenz wrote:
> Hi. I am a swig developer and I also use subversion. In the 1.3.23
> release, we completely removed the ability to link against the runtime
> library. (The runtime library has been depreciated for over a year...)
First of all thanks for taking the time to work on this.
> A couple of points
> 1) subversion has been unusable with SWIG since 1.3.22 or so, since it uses
> a depreciated feature (some hacks have been made around this, but not to my
> liking). <rant>If subversion is using a depreciated feature, then you
> should notify the SWIG developers. If the new feature which is supposed to
> replace the depreciated feature does not work for some reason, then the new
> feature needs to be fixed or the old un-depreciated. It's frustrating when
> users ask on the swig mailing lists why subversion doesn't work.</rant>
<rant>
We were completely unaware that the functionality had been deprecated
until you completely removed it. This is not the first time the SWIG
project has changed things on us in a way that breaks our bindings.
You broke our bindings with 1.3.20 for no apparent reason than you
decided to move some files around. So honestly, if you guys want to
stop receiving emails about us not working... Please try our bindings
with your development versions. Please make some effort to not making
drastic changes to your system without making us aware of them and
giving us time to change.
</rant>
> 2) The patch I attach here requires swig 1.3.24, which is not yet released.
> (Although, we are planning on a release sometime this week). On the other
> hand, the runtime dependency on swig is completely gone. NO libswigpy is
> used anymore. After this patch, users of the python bindings do not need
> swig installed.
Does this patch force everyone to upgrade to 1.3.24? If the answer to
that question is yes then I'm very against applying this patch. Unless
we need functionality from 1.3.24 your patch needs to function against
1.3.19 - 1.3.24 (potentially skipping support for versions that are flat
out broken as you seem to be saying 1.3.22 and 1.3.23 may have been).
Also what about the Perl bindings? Your patch and the resulting
discussion doesn't talk about them at all. Will this technique work
with the Perl bindings?
> 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. Then someone who downloads say subversion-1.0.9 source
> does not even need swig installed to compile subversion, since the .c files
> are already provided. The only people who need swig are those that change
> the .i file or someone building from the repository. Thus requiring 1.3.24
> or higher swig version is no longer that much of a problem.
>
> This patch does not implement the above feature, because I am not that
> knowledgeable about how the build works and how released tarballs are
> built... the rule to build the tarball has to depend on the generated .c
> files, and then include them.
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.
--
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 Tue Nov 30 23:28:27 2004