[Distutils] Duelling SWIG patches
Fri, 23 Jun 2000 10:42:56 +0200
> 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.