[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 22:03:30 CEST

So, there are some "action items" contained in this little exchange.

Let's clear up the other ones:

   - naming schemes -- do we agree that the old fs.py renaming stuff
     sucks, so go back to using the full function names?

   - headers-to-modules ratio -- we'd like to see each header
     handled by its own module, right?

Are there other changes of interest that I'm forgetting?

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

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

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 12 22:08:28 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.