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.