[Distutils] Sample setup.py for Numeric Python

[Anthony Pfrunder]

Hi,

Thanks for the snapshot.  RE the proposed script file format - yes, I
think it is too verbose.  My suggestion is to allow importing and
exporting various types of makefiles (ie Setup, dsw/dsp, unix makefiles).
This way, people can choose the way to build their extensions.  Give me a
couple of weeks and I'll port the code for this to the current setup
format (assuming it doesn't change).

The other suggestion is to add *aquisition* to the system.  This is a
concept invented / named by the DigiCool Zope team.  I have found this is
a fantasic way to handle platform dependances.  I have used this in my
Zope build system to abstract out the def problem [Greg, do you still want
the Zope build system?  I don't have full access to the net so I cannot
use CVS but I can email it to you].  Basically I use a make file style
format where platform deps are handled by loadable makefiles which
override or modify rules.  For example,

MyExtension: SomeDirectory$/Setup $(PLATFORM)$/make.dsw \
	     MyExtensionMetaRule file.c file1.c MyExtension.pyd

Here, MyExtension imports from a Setup file, a MSVC workspace file and
builds the resulting MetaRule (which is modified by the previous 2
imports), the two c sources and finally generates the pyd.  As each c file
is compiled the resulting object files are added to the global variable
OBJS.  Then, if the generation of the pyd uses a compiler needing def
files (or any others...) it is generated as a temp file, used and then
deleted.  The OBJS variable is then reset.  This is what I mean by
aquisition.

A few bits 'n pieces to add... We need to accomedate people using diverse
platforms.  This implies using verbose os.path.join for all paths OR by
supplying a platform to generic converter.  This converter converts
platform file specs to $/ format.  The $/ is replaced with os.path.sep
upon load hence autoconverting to the right format.  Other metachars
include the $(..) format for variables.

The above system has been tested on a subset of Mark Hammond's win32
extensions, the Python Imaging Extensions (including numeric py i think)
and other misc stuff.  The other big thing is that I have converted the
entire Python build system into this format so once I write an exporter
you can build python cross-platform using dist-utils.  I have removed the
need for SED 'n friends and merged freeze and Gordon's freezer so that if
you add pyc/pyo's to the source line it will either freeze it into the
exe or the currently active MPZ file.

The only thing missing now is a cross-platform point 'n click extension
installer!  I think WxPython should do the job ;) 

Cheers,

Anthony Pfrunder
Computer Systems Engineering
University of Queensland