Re: [IMP-dev] SWIG %import

[Daniel Russel <>]

Anyway, am looking in to these things since IMP currently does not work reliably with other swig modules which use IMP. For example, doing

for p in IMP.Particles():

print p

crashes on my linux box if IMP and another swig library are loaded. Try adding that line to anything in the IMPEM tests to see.

On Jan 3, 2008, at 10:47 AM, Ben Webb wrote:

Daniel Russel wrote:

Apparently the %import directive is meant to be used with .i files

rather than .h files.

No, %import is meant to be used with SWIG interface files, just like
%include is. In many cases, regular header files are valid SWIG
interface files, and that's the case with IMP. By %import'ing all of
IMP, you're telling SWIG about a whole bunch of classes it doesn't need
to care about for impEM. So this change is unnecessary - unless it does
actually fix a problem you're having (in which case, add a testcase
which crashes with the current setup and works with your patch).

To quote the manual:

To create the wrapper properly, module derived needs to know the base class and that it's interface is covered in another module. The line %import "base.i" lets SWIG know exactly that. The common mistake here is to %import the .h file instead of the .i, which sadly won't do the trick. Another issue to take care of is that multiple dependent wrappers should not be linked/loaded in parallel from multiple threads as SWIG provides no locking - for more on that issue, read on.

In addition, we are not properly sharing the swig runtime info between

modules. Apparently we need to add " -DSWIG_TYPE_TABLE=IMP" to each

compilation of a _wrap.cc so that the information is properly shared.

On the contrary, you only need to define that if you _don't_ want to
share the information except with other modules that have the same type
table. So we don't need this change either - by default everything is
shared (and since we use namespaces properly we shouldn't conflict with
other SWIG modules). See http://www.swig.org/Doc1.3/Modules.html#Modules_nn2
Admittedly that documentation is a little misleading, so again, if you
need it to fix a problem, add a testcase.

Well, when I don't have it, swig doesn't handle casts correctly across modules, and the manual does explicitly say otherwise:

The runtime functions are private to each SWIG-generated module. That is, the runtime functions are declared with "static" linkage and are visible only to the wrapper functions defined in that module. The only problem with this approach is that when more than one SWIG module is used in the same application, those modules often need to share type information. This is especially true for C++ programs where SWIG must collect and share information about inheritance relationships that cross module boundaries.