Greg Ward wrote:
[sample setup.py] ext_modules = [ ( '_numpy', { 'sources' : [ 'Src/_numpymodule.c', 'Src/arrayobject.c', 'Src/ufuncobject.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/numpy.def' } ),
[/]
First, what d'you think? Too clunky and verbose? Too much information for each extension? I kind of think so, but I'm not sure how to reduce it elegantly. Right now, the internal data structures needed to compile a module are pretty obviously exposed: is this a good thing? Or should there be some more compact form for setup.py that will be expanded later into the full glory we see above?
I'd suggest using a class based approach for the ext_modules data,e.g. class ExtModule: def_file_template = 'Src/%s.def' def get_includedirs(self): return ['./Include'] def get_def_file(self): return self.def_file_template % self.name # etc. class _numpy(ExtModule): name = 'numpy' sources = ('_numpymodule.c','arraymodule.c',...) setup() would then be passed a list of instances (or classes which it then instantiates): setup(..., ext_modules = [_numpy(),...], ...) Advantages are greater incapsulation and more flexibility due to the fact that naming schemes used in the external module can be incoporated into the classes.
I've already made one small step towards reducing the amount of cruft by factoring 'include_dirs' out and supplying it directly as a parameter to 'setup()'. (But that needs code not in the CVS archive yet, so I've left the sample setup.py the same for now.)
The next thing I'd like to do is get that damn "def_file" out of there.
AFAIK, you don't need the def-files anymore. All you have to do is use a tag on every function you wish to export in the source code. Python already works this way and so do all my extensions (the needed macros are in the file mxh.h). -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 109 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/