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