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