[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: <cmpilato_at_collab.net>
Date: 2003-05-12 21:34:32 CEST

Philipp von Weitershausen <philipp@weitershausen.de> writes:

> > * 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.

Aside from that, the patch looks pretty good. It's actually quite
cool what Swig can pull off with those shadow classes -- I asked you
to sell me, and now I'm sold.

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. I'd really like to keep our wrapper code in
real .py files they way it is now.

There are a couple of options I can think of (and I'll just use the
'fs' module as an example). One is to have swig generate modules like
__fs.so and _fs.py, with our custom wrapper code remaining in fs.py.
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.

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.

So, Philipp, what are you thoughts on these things?

---------------------------------------------------------------------
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:39:31 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.