[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] eliminate -noproxy flag to SWIG

From: Philipp von Weitershausen <philipp_at_weitershausen.de>
Date: 2003-05-12 21:56:58 CEST

cmpilato@collab.net wrote:
>>>* Makefile.in
>>> Do not call SWIG with the -noproxy flag: build shadow classes
>>> instead of accessor functions for structs.
>>>* subversion/bindings/swig/*.i
>>> This makes the provided python modules in
>>> subversion/bindings/swig/python/svn obsolete because SWIG needs to
>>> create its own. Thus included the additional code from the now
>>> obsolete modules in the SWIG macros using the %pythoncode directive.
> You're referring to obsolete modules, yet you've not removed anything
> from version control. I'm guessing you're code is meant to get rid of
> subversion/bindings/swig/python/svn/*.py.

Exactly. I guess I forgot to write a log message for that.

> There's only one thing I'm not very fond of, and that's the
> %pythoncode {} blocks which now house the old contents of the *.py
> wrapper scripts we had.

Yeah, I agree, it's ugly.

> The other is to keep our bindings pure, with _fs.so and fs.py, and
> then any wrapper code we do lives in modules with names like
> FileDiff.py, WorkingCopy.py, etc.

+1 here. For example, I already have some code that wraps all functions
in svn_client.h (checkout, import etc.) in a class. This could go into
Client.py, as much as a class wrapping all working copy functions would
go into WorkingCopy.py.

> I guess what I'm getting at is that it's yucky to have our .i files
> growing into these massive sourcefiles with concatenating
> language-specific wrapper code for python, perl, java, ruby, etc. just
> slapped into %python-et-all-code {} blocks.

100% agreed.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 12 21:56:37 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.