Module SciPy.​weave.​swig2_spec

This module allows one to use SWIG2 (SWIG version >= 1.3) wrapped objects from Weave. SWIG-1.3 wraps objects differently from SWIG-1.1.

The code here is based on wx_spec.py. However, this module is more like a template for any SWIG2 wrapped converter. To wrap any special code that uses SWIG the user simply needs to override the defaults in the swig2_converter class. These special circumstances arise when one has wrapped code that uses C++ namespaces. However, for most straightforward SWIG wrappers this converter should work fine out of the box.

Newer versions of SWIG (>=1.3.22) represent the wrapped object using a PyCObject and also a PySwigObject (>=1.3.24). This code supports all of these options transparently.

Since SWIG-1.3.x is under intense development there are several issues to consider when using the swig2_converter.

1. For SWIG versions <= 1.3.19, the runtime code was built either into the module or into a separate library called libswigpy (or something like that). In the latter case, the users Python modules were linked to this library and shared type information (this was common for large projects with several modules that needed to share type information). If you are using multiple inheritance and want to be certain that type coercions from a derived class to a base class are done correctly, you will need to link to the libswigpy library. You will then need to add these to the keyword arguments passed along to weave.inline:

   1. Add a define_macros=[('SWIG_NOINCLUDE', None)]
   2. Add the swigpy library to the libraries like so: libraries=['swigpy']
   3. If the libswigpy is in a non-standard location add the path to the library_dirs argument as library_dirs=['/usr/local/lib'] or whatever.

   OTOH if you do not need to link to libswigpy (this is likely if you are not using multiple inheritance), then you do not need the above. However you are likely to get an annoying message of the form:

   WARNING: swig_type_info is NULL.
   

   for each SWIG object you are inlining (during each call). To avoid this add a define_macros=[('NO_SWIG_WARN', None)].

2. Since keeping track of a separate runtime is a pain, for SWIG versions >= 1.3.23 the type information was stored inside a special module. Thus in these versions there is no need to link to this special SWIG runtime library. This module handles these cases automatically and nothing special need be done.

   Using modules wrapped with different SWIG versions simultaneously. Lets say you have library 'A' that is wrapped using SWIG version 1.3.20. Then lets say you have a library 'B' wrapped using version 1.3.24. Now if you want to use both in weave.inline, we have a serious problem. The trouble is that both 'A' and 'B' may use different and incompatible runtime layouts. It is impossible to get the type conversions right in these cases. Thus it is strongly advised that you use one version of SWIG to wrap all of the code that you intend to inline using weave. Note that you can certainly use SWIG-1.3.23 for everything and do not have to use the latest and greatest SWIG to use weave.inline. Just make sure that when inlining SWIG wrapped objects that all such objects use the same runtime layout. By default, if you are using different versions and do need to inline these objects, the latest layout will be assumed. This might leave you with holes in your feet, but you have been warned. You can force the converter to use a specific runtime version if you want (see the swig2_converter.__init__ method and its documentation).

Prabhu Ramachandran <prabhu_r@users.sf.net>