Re: svn commit: r15653 - branches/python-bindings-improvements/build/generator
Thanks for all your feedback! This is very helpful. More details below.
On 8/10/05, Branko ╚ibej <firstname.lastname@example.org> wrote:> Is this really a problem? gen_win.py has a find_swig function that> unconditionally ises os.popen4 to get the swig version. Nobody ever> complained.It's rare to see Windows users who have Python 1.x installed. However,on Unix, it's common to have Python 1.x on your system, installed as"python". As such, it's a good idea to keep the Unix Makefilegenerators Python 1.x compatible.
> And wouldn't it be nice if we had _one_ function in the generator for> finding the swig version?Absolutely. I didn't notice the "windows" implementation of find_swigwhen I first wrote this function. It'd be much better for both theUnix and Windows implementations to inherit from a sharedcross-platform implementation. I'll implement this.
> I've finally found time to take a quick look at the generator changes> and I'm ... worried. gen_swig.py's generator inherits from the> unix-makefile generatorOops. This file doesn't use any Unix specific functionality, so itwould work fine if it inherited from "gen_base" instead of gen_make.
> but a) contains windows-specific stuffReally? Where? This module is cross-platform, so it needs to work onboth Unix and Windows.
> and b)> contains utilities (such as $PATH search??? what on earth for?)$PATH search can be useful for verifying the existence of anexecutable. We currently use this feature to double check whether the"apr-config" executable exists and is in your path. It's an easysanity check.
> that, at> best, belong in a generator utilities module or in gen_base.py.Definitely! This code is cross-platform, so it really belongs ineither a generator utilities module or in gen_base.py.
> This is the sort of spaghetti code we've been struggling to keep out of> the generator. Merging this to trunk as it is now would make me very> uncomfortable.I'm new to the Makefile generator, so I made some newbie designmistakes. However, these are fortunately easy to fix. Here's my plan:1. Move cross-platform path-finding functionality from gen_swig.py andgen_win.py into a common base class, so that both Unix and Windowsimplementations can benefit. I'll call this "gen_path.py".2. Move SWIG file generation from gen_swig.py into a separatecommand-line utility, which can be called from both the Unix and theWindows generators and makefiles. As a side-benefit, this change willallow us to automatically regenerate the SWIG-wrappers for each ".h"header file on-the-fly when the user types "make".3. Move Makefile generation from gen_swig.py into gen_make.py. Afterthis, there'll be nothing left in gen_swig.py, so we can delete it.
Thanks for your help!
-- David James -- http://www.cs.toronto.edu/~james
Received on Wed Aug 10 13:43:16 2005
This is an archived mail posted to the Subversion Dev