On 8/16/05, Branko Èibej <brane@xbc.nu> wrote:> Daniel Berlin wrote:> > >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.> >> >> But it doesn't generate makefiles, right? So what's wrong with> inheriting from gen_base?[...]> Well, if we have> > gen_base --> gen_swig> > and some ifs in gen_swig, then fine. But> > gen_base --> gen_make --> gen_swig> > looks like a lie to me.
gen_base is an abstract base class, so gen_swig needs to define"_extension_map" in order for it to be instantiated with gen_base as aparent. Right now, we can fulfill this requirement by inheriting from"gen_make", which defines "_extension_map". This is a temporaryworkaround until we refactor the generator classes.
> >There is probably some code that could be moved into the generator> >utilities, etc. David has agreed to do so.> >> >> Yup. The whole generator thing could probably do with another round of> refactoriing, but that's not David's job. (Yet. :-p )Definitely! I'm thinking of creating three new helper modules: generator.util.external -- Calculating paths and options forexternal libraries generator.util.include -- Parsing include files and calculatinglists of include files generator.util.options -- Parsing build.conf and options passed onthe command-line
These helper modules will allow us to simplify the generator, andreduce interdependencies. With these helper modules, there'll be noneed for strange-looking inheritance trees (e.g., gen_swig depends ongen_make).
These changes can wait until after the merge, though.
> >Other than that, assuming it is tested well by others, i believe it> >should go in.> I've not tested tnis on Windows yet, and I don't know if anyone has...> lack of time on my part again, etc...C. Mike has done some preliminary testing on Windows.
> >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> >there.> >> >> I think a "svn diff -rFOO:BAR> http://svn.collab.net/repos/svn/branches/python...." is sufficient.> There's n point in posting something anyone can pull from the repository. :)It's nice to be able to look at the changes in your email reader, soyou can comment on the individual changes. I think there are somefolks who prefer this.
Cheers,
David
-- David James -- http://www.cs.toronto.edu/~james
Received on Wed Aug 17 17:25:00 2005