[Distutils] Duelling SWIG patches

[Thomas Heller]

> Well, I was inspired by Thomas' patch for SWIG support to come up with
> my own patch.  Here it is: completely untested, so I haven't checked it
> in yet.  (I don't have SWIG installed at home, so I figured I'd let
> someone Out There who actually uses it test this for me.  Remember:
> laziness is a virtue!)
> 
> Note that Thomas' patch was Windows/C++-centric; mine tries to be
> OS-agnostic, but is C-centric.  Is it possible to tell from a SWIG .i
> file whether it is destined to be C or C++?  I can't think of a good way
> to do it, but then my knowledge if SWIG is roughly epsilon.  (Out of
> curiosity, I took the manual home and read it about three years ago.  It 
> struck me as being *way* to easy, and I wanted to write Perl extensions
> like a *real* man.  Ahh, the folly of youth...)
> 
I don't like this patch.

While I won't argue whether ccompiler is an appropriate superclass
for swig, swig shares some important properties:

Swig has command line flags to specify include directories -I<dir>,
libraries -l<ifile>, define symbols -Dsymbol like C-compilers.
Other options which are maybe usefull for python extensions
are -t <typemap file>, -shadow (create shadow classes),
-module name (set module name) and maybe more.

From this I have the impression that swig should be a separate class
implemented in swig.py, and there should be distutils command line
flags for setting the above options (and also the -c++ option).
Although I did not implement them so far.

(Sidenote: I also needed a swig-object in build_ext for my setup-script
for win32all. I had to extend distutils in the setup-script
because there are also exe-files to be built from C++
and swig sources).

As I pointed out in a separate post, there should also be an option
to specify C or C++ processing.

If I find time, I will submit a new patch.

Thomas