On 16 June 2000, Thomas Heller said:
The included source code and patch implements a swig class (derived from ccompiler).
Disclaimer: I haven't looked at SWIG or read its docs in something like 3 years, I have only scanned your patch, and I have barely thought about the right way to implement SWIG support. That said, this seems like a strange way to do it. I had been vaguely thinking of adding a pre-compilation step to the build_ext command; the idea of a new CCompiler class for something that really isn't a C compiler at all hadn't occurred to me, probably because it's just plain weird. Any particular reason you did it this way?
Simply include 'xxx.i' files into your extension source-files, and swig will be used to generate 'xxx.cpp' files, which will then be compiled and linked.
That can probably be handled by a little conspiracy between the Extension class and the build_ext command; again, I fail to see the benefit of a CCompiler class for this.
Other stuff included (only useful for the windows crowd) Resource scripts (*.rc) and message compiler files (*.mc) can also be used as extension source files, and MSVC will invoke rc.exe and mc.exe to create .res files and pass them to the linker.
Sounds uncontroversial. Can you submit that as a separate patch? Thanks! Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ I brought my BOWLING BALL -- and some DRUGS!!