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