[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

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.