Dan Schult wrote:
Lars Immisch wrote:
I don't think so. In the first place, swig should create .py files only if -shadow is passed, and I see no obvious support for this argument in the distutils code.
Swig is run without include path arguments (-Ifoo), macro definitions or undefs and only one possible extra argument (-cpp).
Are you sure you have the latest version of Swig (and distutils)?
Yes; I am using SWIG 1.3.21 (but my makefiles are from the days of SWIG 1.3.5).
But you are right. Since SWIG 1.3.14, -shadow is default. See [1] below.
It handles include directories just fine for me and it creates .py files by default (without -shadow)
Do you have headers that are included via %include in the .i file (note %include instead of #include)?
Standard #includes are just emitted to the wrapper code; the C compiler gets the right arguments and things just work (tm).
The %includes are read by swig itself - swig takes the standard -I<foo> arguments, but they are not currently passed.
(I need this to %include header files with type definitions that are later used by %typemaps or %extends.)
It seems that perhaps the best way to solve my problem is to add a line in build_ext.py that moves the python modules swig creates after it creates them.
Sounds like a pragmatic solution to me.
It sounds like you are having many more issues though...
Just extra arguments.
I also find -modern quite important, but this could/should be handled by extra_swig_args. See [2].
- Lars
From SWIG-1.3.21/CHANGES:
[1]
07/23/2002: beazley *** IMPORTANT CHANGES TO THE PYTHON MODULE ***
(1) The Python module now enables shadow/proxy classes by default. This means that two files are always created by SWIG. For instance, if you have this:
// file: foo.i %module foo ...
[2]
10/31/2003: beazley Incorporated patch: [ 829325 ] new Python Module options and features. Robin Dunn writes:
This patch makes a number of changes to the SWIG python module.
...
5. Added a -modern command-line flag that will cause SWIG to omit the cruft in the proxy modules that allows it to work with versions of Python prior to 2.2. The result is a simpler, cleaner and faster python proxy module, but one that requires Python 2.2 or greater.
-
Lars Immisch