[Swig-user] Multiple modules and Python absolute paths with %import

[Ben W. <be...@sa...>]

Is it possible when building multiple modules and wrapping for Python to
get Python imports that are a) correct and b) absolute? For example, say
I have two C++ modules 'a' and 'b' that live in the 'foo' package, and I
want to wrap each one separately to get two Python modules 'foo.a' and
'foo.b'. So a.i could look like:

%module(directors="1") "foo.a"
%{
#include "a.h"
%}
%include "a.h"

Unfortunately this doesn't work, for two reasons:
1. The DSO comes out as "_foo.a.so" which looks odd. This can be fixed
   easily by adding "-interface _foo_a" to the swig command line though.
2. The module name is placed directly in CPP macros (most obviously the
   header guard in a_wrap.h comes out as SWIG_foo.a_WRAP_H_), and
   '.' is not valid for macro names.
(2) seems to be a bug; perhaps '.' should be replaced with '_' when
generating the header guard, or it should use the value from -interface
(_foo_a in this case) rather than -module (foo.a)?

(Even if it did work, it seems a little Python-specific. "foo.a" may be
a valid module name in Python, but not necessarily in other languages.)

OK, so a solution which has been working well for me so far is to call
the module "foo_a" instead. This generates a DSO "_foo_a.so" which is
fine, and a Python file "foo_a.py". It is then trivial to "mkdir foo; mv
foo_a.py foo/a.py; touch foo/__init__.py" and then "import foo.a" (or
similar for foo.b) works correctly from a Python shell.

But now we run into a problem if 'b' extends a class in 'a', i.e. b.i
looks like:
%module(directors="1") foo_b
%{
#include "b.h"
%}
%import "a.i"
%include "b.h"

The problem is that foo_b.py now contains the line "import foo_a" rather
than the desired "import foo.a" and so after moving things to the
correct directory structure (foo/a.py, foo/b.py) "import foo.b" fails
because it can't find a module called "foo_a".

One workaround for this problem is to write the %import as
%import(module="foo.a") "a.i"
i.e. explicitly overriding the name of the 'a' module. But this seems
ugly since I have to explicitly do this for every other package that
uses a.i. The alternative is to do a search and replace on foo_wrap.h
and replace "foo.a" with "foo_a".

Are there any other more elegant solutions to this problem?

	Ben
-- 
be...@sa...                      http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
	- Sir Arthur Conan Doyle