On Jan 22, 2009, at 11:43 AM, Johnathan C. wrote:
On Thu, Jan 22, 2009 at 11:39:25AM -0500, Michael D. wrote:
After further investigation, this is a SWIG 1.3.37 bug.
I retract this statement. I’m no longer sure if it’s a bug. Issuing
“swig -help” in the different versions results in:
-outdir <dir> - Set language specific files output directory
-outcurrentdir - Set default output dir to current dir instead
of input file’s path
-outdir - Set language specific files output directory
This seems to imply a “split” in where output files are written:
By default in 1.3.36, all files are written to the output directory
(the one from which the ‘swig’ command was called).
By default in 1.3.37, C++ files are written to the output directory,
while non-C++ files are written to the input directory (the one
containing the input .i file). To get the output directory correct,
one now needs to specify “-outcurrentdir” (or “-outdir .”, which
should be backwards compatible back to about version 1.3.20). It is
clear from SVN  that this change is intentional, hence I’m inclined
to believe that the SWIG docs are just out of date and this is a new
feature in 1.3.37.
Thanks for looking into this. What platform configuration are you
using that is shipping 1.3.37?
MacPorts keeps pretty up to date on most releases, which can be a good
or bad thing.
I will submit a bug fix to the SWIG folks, since there
doesn’t seem to be one yet
I will submit a complaint to them, to resolve this issue. If they
want to go with the “split” system that’s fine, but it broke backwards
compatibility and should be highlighted somewhere … and the
documentation needs to be updated to reflect this -important- change.
That said: The state of use of SWIGPYTHONFLAGS in individual
varies significantly (some do not even us it, instead just recreating
those flags in the local Makefile.am) and should probably be
That would be a useful patch. Thanks for volunteering
I’ll get there. I’m inclined to include “-outdir .” in
SWIGPYTHONFLAGS just to provide both backward and forward compatibility.
BTW> What’s the estimated timeline for 3.2 release? I’m going to
release a variety of OSX-specific GNU Radio items at that time,
including Portfiles for the various components.