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

python-bindings-improvements review

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-08-17 01:01:07 CEST

So i reviewed the python-bindings-improvements branch.

I've assumed for the purposes of review that the swig code it generates
works (and did test it on my linux machine with the python scripts we
have). I have to leave it to others to verify this as well, on
platforms like win32, ruby, perl, etc.

I pointed out some moderate and minor things to David on IRC, like some
missing overview comments about what gen_swig is actually doing.

I don't see any major problems in the design or implementation, and in
fact, think it's a lot cleaner than what we do now.

However, since Branko seemed to be so against it, i thought i'd just
mention why i don't really agree that this is "spaghetti code".

First off, i should say that i don't agree with the idea that it
shouldn't t inherit from the Unix Makefile generator. Swig binding
generation really is like unix makefile generation, much moreso than
anything else. It So the fact that it inherits from the unix Makefile
generator really doesn't bother me that much.

The number of windows specific things in it is actually pretty small.

It's small enough that i think the cost of abstracting it and having a
design like:

           / \
          / \
         / \
        / \
       / \
      / \
     / \
gen_unix_swig gen_windows_swig

is not really worth it, and i doubt it will become worth it (you guys
can beat me up later if i turn out to be wrong :P).

There is probably some code that could be moved into the generator
utilities, etc. David has agreed to do so.

Other than that, assuming it is tested well by others, i believe it
should go in.

I'm not sure the procedure for large branch merges where it's unlikely
you can break it up into more than 2 or 3 patches.

I told David he should probably post the invariably huge patch against
head and let people pick at it a bit as a start, and we'll go from

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 17 01:02:59 2005

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.